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CONDITIONAL PURCHASE OFFER MANAGEMENT SYSTEMS 

Ftdd of the Invention 

The pieseni invention relates to b method and apparatus for processing 
S the sale of products using electronic networks to custonieis who have snbmitied an offer 
for the purchase of such products. 

Background of the Invention 

Most systems for processing Ihe sale of products are seller-driven, 

10 whereby the seller prices, packages and configures the product, and the buyer decides 
whether or not to- accept. Traditionally, the seller must attract buyers and complete the 
sale. Thus, in a seller-driven system, the advertising cost of the transaction and ihe 
attendant risks that such advertising will be unsuixessful falls upon the seller. 

Typically, goods and services are sold in a retail environment using a 

15 seller-driven protocol, whereby the seller generally sets a non-negotiable price that the 
buyer may accept or reject. Other foms of commerce provide more flexibility and 
permit the exchange of offers and counteioffeis. In an aiiction, for example, the buyer 
does not find the seller, rather the seller attracts numerous buyers who colteciiveiy 
determine the final selling price, which the seller may subsequently reject unless the 

20 item auctioned is being sold without a reserve. Other commerce systems, such as 
NASDAQ or the New York Stock Exchange (NYSE), are exchange-driven, where 
buyers and selleis are matched by offering an efficient, fair and orderly marketplace. 
Such exchange-driven systems favor neither bayeis nor sellers, but simply effectuate 
comraunicatioits that allow for the matching process to lake place. An example of an 

2S automated exchange-driven commerce system for trading futures is disclosed in United 
States Patent Number 4,903.201 . 

A buyer-driven system, on the other hand, is one where the buyer 
dictates the lenns of the offer and the seller dM^ides whether or not to accept. A "help 
wanted" advertisement, for example, is a buyer-driven inquiry since the employer is 
30 looking to locate and buy the services of a qualified employee. The inquiry is 
advertised to a large number of potential employees, who may respond by submitting 
their resumes to the prospective employer. Generally, bnyer-iliiven systems ate more 
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preferable than other systems for processing (he sale of products. For example, buyer- 
driven systems provide buyers with more control over the terms and conditions of the 
purchase of a desired product Additionally, when a large number of potential sellers 
exist, but those sellers do not have the resources to advertise globally, buyers can take 
S the initiative to communicaie their needs to the sellers. 

Unilateral buyer-driven systems seek to consummate contracts between 
buyers and sellers based on acceptance of an offer by performance of a designated task. 
For example, in a reward system, a "buyer' broadcasts or publishes an offer for a 
reward lo anyone who completes a particular task. Thus, unilateral systems can be 
ID utilized only for limited types of transactions thai allow for accepiahce by performance. 
Bilateral buyer-driven systems, on the other hand, seek to consummaie contracts 
between buyers and sellers based on mutual promises to perform. Bilateral buyer- 
driven syiitems. however, require buyers to invest a lot of time, money and other 
resources to locate an indefinite number of potential sellers and communicate the 
IS buyer's purchasing needs to each seller. Any benefits to the consumer with 
conventional bilateral buyer-driven systems, however, inchiding a potentially lower 
price, are typically outweighed by the amount of time and money expended in the effort. 
In addition, buyer-driven systents impose inherent costs on sellers as well. If each 
buyer has a different set of purchasing specifications and communicate.'; his needs using 
20 non-uniform language, sellers must pay a substantial cost to review and understand each 
individual request. Moreover, sellers are often not amenable to customizing (heir 
products for individual buyers. 

An example of a regularly used bilateral buyer-driven process is the 
system utilized by large organizations, such as companies or governments, who want lo 
25 purchase signiricant amounts of goods or services at the lowest possible price. Initially, 
purchasers formulate a detailed written specification, typically called a "Request for 
Proposal* (RIT), setting forth the quaniiiies and requirements of what ihey are looking 
to buy. Once fintdized, the RFPs are then distributed to a list of known potential 
suppliers. Potential supidiers then screen the RFPs to identify those that they rnighi be 
30 able to fuinil, and thereafter determine whettaier or not to invest the necessary time and 
effort to submit a formal binding proposal to the buyer by a deadline established in the 
RFP. Once submitted, the proposals are evaluated by (he buyer, and the supplier 
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corresponding to the selected proposal is notified that it has "won" the business at the 
price quoted. 

Large organizations can take advantage of the benefits afforded by the 
RFP process because their volume buying lepresents a wonhwhile oppoituniiy for 
5 suppliers to compete for their business and large organizations have the resources to 
communicate their buying needs to a sufficient number of suppliers. As a result, large 
organizations can often achieve substantial unit cost savings, especially on commodities 
or commodity services (such as paper clips or long distance service) and on perishable 
items (such as airline tickets and hotel rooms). Individual consumeis, however, cannot 
10 effectively participate in such bilateral buyer-driven systems because they generally do 
not have the buying power and resources of large organizations. 

As commerce seeks to utilize the inherent advantages of the Internet, 
many systems for processing the sale of product^, such as malls, catalogs and auction 
houses, are being implemented on the Internet. These approaches generally seek to 
IS create better seller or exchange-driven systems whereby the sale of goods and ."wirvices 
is made more efficient. While there have been some aiiempls to u<x the Internet to 
effectuate bilateral buyer-driven transactions, those attempts have been largely 
unsuccessful. For example, buyers can post "wanted' advertising at little or no cost on 
"bulletin board" type Internet sites. Thus, consumers can essentially po.it their own RFP 
20 to a large number of sellers willing to sell them the exact product they are looking for. 
In practice, however, it is impractical for potential sellers to frequent the various 
"bulletin board" sites or respond to the individual RFPs which typically have diverse 
fonnats. conditions, terms, and language styles. In addition, sellers are deterred from 
using such a process because there is (i) no guarantee of the authenticity of the RFP. (ii) 
25 the cost of negotiating with individual consumers is often too high, and (iii) it is difficult 
to enforce any agreement (including payment guarantees) which may be reached 
between the consumer and the seller. In turn, the absence of a critical mass of sellers 
reduces the incentive for buyers to post their RFPs. 

Many industries, as well as consumeis, would benefit from an effective 
30 bilateral buyer-driven system. Recently, for example, the travel industry has 
experienced explosive worldwide growth. As travel capacity continues to increase, it is 
expected that capacity will outpace projected traveler" volumes, thereby reducing 
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utilization and putting piessuce on pricing. In order to deal with such pricing and 
inventory challenges, many travel-related selleis have developed sophisticated revenue 
management-systems (RMSs) to optimize revenue by dynamically setting the price for 
available inventory. Generally, when inventory is first added by a seller, the seller's 
5 revenue management system attempts to maximize revenue for the inventory by 
establishing a plurality of price classes and then allocating the inventory and price 
assigned to each price class. The revenue management system thereafter continues to 
monitor the actual demand within each price class relative to forecasted demand, 
dynamically reevaluating the inventory allocation and pricing of each price class for 
10 given inventory. 

While conventional revenue management systems employ sophisticated 
tools to anticipate future travel needs, forecasting errois invariably lead to unanticipated 
excess capacity. In addition, a seller can utilize its revenue management system to 
foreca.st anticipated excess capacity, such as excess capacity on a given flight associated 
15 with seats that are predicted to be empty. Punhermbrc. unexpected external events, 
such as a price war or extreme weather conditions, can also affect a seller^ excess 
capacity. Thus, in an attempt to reduce such excess capacity, sellers periodically 
reevaluate the inventory allocation and pricing. Travel-related sellers cannot simply 
discount the published prices for such unsold inventory, however, without either starting 
20 a price war or compromising their own underiying price structure (i.e., without also 
leducing its full-fare prices for fuU-faic travelers). Thus, there is currently no effective 
way for travel-related sellers to dispose of such excess capacity. 

Travel-related sellers recognize that there Is a large source of latent 
demand associated with leisure travelers who are willing to travel at a favorable price. 
25 There is currently no effective way, however, for such sellers to receive an offer from a 
buyer for leisure travel at a particular price set by the buyer, below the seller^ published 
price. In particular, there is no effective way for the seller to be confident that if the 
seller accepts the buyer's offer, the buyer will travel in accordance with the offer, 
without using the information to asceruin the seller^ underiying level of price 
30 flexibility, which, if known to a seller^ competitors or buyers, could dramatically 
impact the seller^ overall revenue structure. 
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Similarly, with the long distance telephone maifcet becoming nearly 
saturated with supply, competition among long distance earners for new business has 
increased dramatically. Although the costs associated with long distance calls have 
' dropped and are expected to continue dropping dramatically in the United Stales and 

5 Other countries as the result of increased competition, the cost of a long distance call 
remains sufficiently high to discourage many people from placing as many long 
distance calls as they would like. In addition, most callers are typically unfamiliar with 
the rate structure associated with placing calls lo various geographical areas at various 
times of day. Thus, the inability lo identify and control the cost of a long distance call 

IC has further contributed to the reluctance of many people to place more long distance 
calls. 

While many large customers, such as corporate customets. often have 
.sufficient leverage to negotiate their long distance rates with a long distance carrier, or 
10 permit carriers to bid for their account, it Is impractical, given current telephone 

15 systems, for long distance providers lo individually negotiate long distance rates with 
the average consumer. In addition, many large customers have accounts with a number 
of different long distance carrieis, and employ "least cost touting" technology in their 
proprietary private branch exchange (FBX) switches or other customer-premises 
equipment. This technology enables them to select the most cost-effective carrier on a 

20 per-call basis using stored rate information. Again, such a cost-reduction solution is not 
available to the average consumer, who typically has only one long distance provider. 
While systems have been developed to allow consumers to identify a long distance 
carrier offering the most cost-effective published rate to complete a call, such systems 
do not facilitate realtime negotiation with individual carriers, or pemnil one or more 

25 telephone calls to be completed in accordance with resti-iciions spcciried by the calling 
party. 

In addition, conventional commerce systems limit the ability of resellers 
of tickets for events, such as a concert, play or sporting event, to advertise ticket 
availability and complete a ticket transaction. Currently, ticket resellers may utilize 
30 classified adveilisemenu, electronic bulletin boards or "chat rooms" on the Internet to 
advertise ticket availability. Such advertisemenu are difficult to remove from the 
public realm once the tickets arc resold. Thus, a person selling a ticket may get 
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inquiries after the ticket has been sold, h addition, die buyer requires physical 
possession of the actual ticket, and delivery immediately prior to the event may be 
problematic. Furthermore, buyers and sellers of tickets possess a general distrust of 
each other. Unless a buyer is face-io-face with a ticket reseller, the buyer Is typically 

5 unwilling to pay for tickets without sonie assurance of delivery. Likewise, a ticket 
reseller is typically unwilling to deliver tickets without payment in advance. 
Conventional ticket reselling systems, however, do not pronde any mechanism for 
guaranteeing the authenticity of either the buyer or the seller. 

In addition to the above-described drawbacks of known commerce 

10 .systems, sellers often require information relevant to a buyer's offer from a third party 
in order to determine whether to accept the offer. For example, potential buyers of 
aitworks require that the artworks be accompanied by a tmsted third party's "seal of 
approval." Such a seal would typically authenticate that the artworks ate genuine, and 
also appraise their value. Similarly, potential lenders of funds require the credh history 

15 or a "credit score" of a potential borrower. Lenders would typically not accept .such 
critical information from the potential borrower, since the bonower might try to alter 
the information to appear more credit-wonhy. The credit information must come from a 
trusted third party. 

Accordingly, an offer to borrow funds, which would include borrowcr- 

20 specified conditions, such as an interest rate and loan amount, would, by itiself, be 
insufficient for the lender to detemiine' whether to accept the offer. Potential lendei? 
would not be able to ascenain whether the offer was acceptable in tenns of credit riiik 
and credit worthiness. Thus, buyers would not be able to usefully make such offeis. 
Current systems for evaluating borrower credit risks in connection with the sale of 

25 financial producu, such as the system disclosed in United Sutes Patent Number 
S,61 1,0S2, do not permit potential bonowera to specify desired loan conditions. In 
addition, the system disclosed in United States Patent Number 5,611,052 does not 
prevent people who do not intend to buy from inundating a seller of financial pioducts 
with worthless loan applications. 

30 As apparent from the above deficiencies with conventional systems for 

processing the sale of products, a need exists for a bilateral buyer-driven system, 
capable of being utilized by individual consuioers to communicate their punrhasing 
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needs globally to potential sellers, which addresses the deficieiKies of the prior ait. A 
further need exists for a bilateral buyer-driven system which authenticates the terms and 
conditions of buyer offers. There is also a need for third party administration in such a 
bilateral buyer-driven system to resolve contract disputes between the parties, increase 
buyer and seller confidence in the system and establish standard protocols, formats, terms 
and language to be used in buyer-specified oflers. A iiirther need exists for a system that 
permits a seller to sell excess capacity when actual demand fails to meet forecasted 
demand. Another need exists for a buyer-driven system that permits a buyer to obtain 
products at a price set by the buyer, typically below the published price of the product. 
Yet another need exists for a system that peimits sellers to stimulate sales of excess 
inventory or capacity, without compromising the seller's published price structure. 
Finally, there is a further need for a system that allows sellers to evaluate the acceptability 
of an offer from a buyer in light of information relevant to the offer fimn a third party. 
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Summary of the Invention 

In accordance with a first aspect of the present invention liere is provided a 
computer device for consimiroating a binding contract between a remote prospective 
buyer and a remote potential seller, said computer device comprising: 

a memory device; and 

a processor disposed in communication with said memory device, ssdd processor 
configured to receive from the remote prospective buyer (a) a binding purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a general 
purpose financial account from which fiinds may be paid for a purchase meeting said at 
least one condition; said processor Anther configured to transmit the purchase offer to a 
plurality of remote potoitial sellers, receive from at least one of the remote potential 
sellers an unconditional acceptance of the offer, and transmit notification to the buyer that 
the binding purchase offer was accepted by a first-accepting seller without revealing the 
identity of the seller. 

In accordance with a second aspect of the present invention there is provided a 
computer device for consunmiating a binding contract between a remote prospective 
buyer and a remote potential seller, said computer device comprising: 

a memory device; and 

a processor disposed in communication with said mranoiy device, said processor 
configured to receive 6om the remote prospective buyer (a) a binding purchase offer 
containing at least one condition, and (b) a payment identifier fi>r specifying a general 
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purpose financial account of an electronic settlement system from which fiuids may be 
paid for a purchase meeting said at least one condition; said processor fiuther configoied 
to transmit the binding purchase oiTer to an electronic buying network of remote potential 
sellers, receive from at least one of the remote potential sellers an unconditional 
acceptance of the binding purchase offer, iiutiate the use of the payment identifier to 
render payment for said purchase by charging said general purpose financial account of 
said electronic settlement system and transmit notification to the buyer that the binding 
purchase offer was accepted by a first-accepting seller without revealing the identity of 
the seller. 

In accordance with a third aspect of the present invention there is provided a 
system for processing airline ticket sales, said system comprising: 

a communications port for obtaining a binding purchase offer for travel from a 
customer and one or more rules from a plurality of sellers of airline tickets, said binding 
purchase offer containing at least one customer-defined condition and each of said rules 
containing one or more airline-defined lestrictions, said airline-defined restrictions 
including a price which is not disclosed to said customen and 

processing means for comparing said binding purchase offer to said rules to 
determine whether any of said sellers of airline tickets is willing to accept said binding 
purchase offer if said customer-defined conditions satisfy said airline-defined restrictions 
of at least one of said rules, and for providing an acceptance of said binding purchase 
offer to said customer if said at least one customer-defined condition satisfies said 
restriction. 

In accordance with a fourth aspect of the present invention there is provided a 
system for processing the sale of goods or services, said system comprising: 

a commimications port for obtaining a binding purchase offer from a customer 
for the purchase of said goods or services and one or more rules from a plurality of 
sellers, said binding purchase offer containing at least one customer-defined condition 
and each of said rules containing one or more seller-defmed restrictions, said seller- 
defined restrictions including a price which is not disclosed to said customer; and 

a processor for comparing said binding purchase offer to said rules to determine 
whether any of said sellers is willing to accept said binding purchase offer if said 
customer-defined conditions satisfy said seller-defined restrictions of at least one of said 
rules, and for providing an acceptance of said binding puichase offer to said customer if 
said at least one customer-defined condition satisfies said restrictions. 
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In accordance with a fiflh aspect of the present invention there is provided a 
method of processing airline ticket sales, said method comprising the steps of: 

obtaining a binding purchase offer for travel from a customer, said binding 
purchase offer containing at least one customer-defined condition including a price; 

5 identifying one or more rules from a plurality of selleis of airline tickets, each of 

said rules containing one or more aidine-defuied restrictions including a price which is 
not disclosed to said customer, 

comparing said binding purchase offer to said rules to determine whether any of 
said sellers of airline tickets is willing to accept said binding purchase offer if said 

10 customer-defined conditions satisfy said airline-defined restrictions of at least one of said 
rules, and providing an acceptance of said binding purchase offer to said customer if said 
at least one customer-defined condition satisfies said airline-defined restrictions. 

In accordance with a sixth aspect of the present invention there is provided a 
system for processing cruise ticket sales, said system comprising: 

\! a communication port for obtaining a binding purchase offer for travel tin>m a 

customer and for receiving one or more rules from a plurality of sellers of craise tickets, 
said binding purchase offer containing at least one customer-defined condition including a 
price and each of said rules containing one or more cruise operator-defined restrictions 
including a price which is not disclosed to said customer; and 

20 a processor for comparing said binding purchase offer to said rules to determine 

whether said customer-defmed condition satisfies each of said cruise operator-defined 
restrictions of at least one of said rules, and for providing an acceptance of said binding 
purchase offer to said customer if said customer-defined condition satisfies said 
restrictions. 

25 &i accordance with a seventh aspect of the present invention there is provided a 

system for processing cruise ticket sales, said system comprising: 

a communications port for obtaining a binding purchase offer for said cruise 
ticket from a customer and for providing said binding purchase offer to a plurality of 
potential sellers of cruise tickets, said binding purchase offer containing at least one 
30 customer-defined condition and a payment identifier for specifying a general-purpose 
account from which fimds may be paid; and 

a processor for determining if one or more of said carriers accepts said binding 
purchase offer, for binding said customer to purchase said cruise ticket if an accq>tance is 
received for said binding purchase offer and for providing an ace^itance of said binding 
urchase offer to said customer. 
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A more complete understanding of the present invention, as well as further 
features and advantages of the present invention, will be obtained by reference to the 
following detailed description and drawings. 

Brief Description of the Drawings 

Figure I illustrates a first embodiment of the present invention. 

Figure 2 is a block diagram showing one embodiment of the central controller. 

Figure 3 is a block diagram showing one embodiment of the seller interface. 

Figure 4 is a block diagram showing one embodiment of the buyer interface. 

Figure 5 illustrates an embodiment showing how a conditional purchase offer is 
generated. 

Figure 6 illustrates an embodiment showing the acceptance of a conditional 
purchase offer by the cei\tral controller. 

Figure 7 illustrates an embodiment showing the activation of a conditional 
purchase offer. 

Figure 8 illustrates one embodiment of die maintenance of active conditional 
purchase offers. 

Figure 9 illustrates an embodiment showring the seller selecting a conditional 
purchase offer. 

Figure 10 and 1 1 illustrate an embodiment showing ttie binding of a conditional 
purchase offer. 

Figure 12 illustrates an exemplary procedure for exchanging goods and payment 
between buyer and seller. 

Figure 1 3 illustrates an exemplary payment mettiod. 

Figures 14 through 17 illustrate an exemplary authentication procedure using 
cryptographic protocols. 
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Figures 18 and 19 tllusuate an exemplary embodiment for counteroffers 



by a seller. 



Figure 20 illustrates an embodiment showing the use of a trusted server 



and a bonding agency. 



s 



Figure 21 is a schematic block diagram illustrating a conditional 



purchase offer (CPO) management system in accordance with one embodiment of the 
present invention. 

Figure 22 is a schematic block diagram of the exemplary CPO 
management central server of Figure 2 1 . 
"> Figure 23 is a schematic block diagram of the exemplary secured airline 

scrverof Figure 21. 

Figure 24 is a schematic block diagram of the exemplary central 
reservation system of Figure 2 1 . 

Figure 25a is a schematic block diagram of the exemplary reservation 
1 5 management system (RMS) of Figure 2 1 . 

Figure 25b illustrates the interaction between the RMS. the airline 
reservation system and the various databases depiaed in Figure 2Sa. during a 
conventional pricing and allocation process and the CPO rules generation process of 
Figure 39. 



20 




25 22. 



Figure 28 illustrates a sample table fronn the flight schedule database of 



Figures 22 and 24. 



Figures 29a and 29b. collectively, illustrate a sample table from the CPO 



database of Figure 22. 
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Figure 30a illustrates a sample table from the secured airlines rules 



database of Figure 23. 
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Figures 30b and 30c, collectively, illustrate aitemaiive sample tables to 
the secured airlines rules database of Figure 23. 

Figure 31 illustrates a sample table from the counteroffer rules database 

of Figure 23. 

5 Figure 32 illustrates a sample table from the secured airline audit 

database of Figure 23. 

Figure 33 illustrates a sample table from the pricing and restrictions 
database of Figures 24 and 2Sa. 

Figure 34 illustrates a sample table from the seat allocation database of 
10 Figures 24 and 25a. . 

Figure 35 illustrates a sample table from the foreca-si and demand 
analysis database of Figiue 2Sa. 

Figures 36a through 36c, collectively, are a flow chart describing an 
exemplary CPO management process implemented hy the CPO nuuiagemeni central 
15 server of Figure 22. 

Figures 37a and 37b. collectively, are a flowchart describing an 
exemplaiy evaluation process implemented by the secured airline server of Figure 23. 

Figure 38 is a flow chart describmg an exemplary audit process 
implemented by the secured airline server of Figure 23. 
20 Figure 39 is a flow chart describing an exemplary CPO rule generation 

process implemented by the revenue management system of Figure 25a. 

Figures 4Qa and 40b, collectively, illustrate an alternative sample (able 
from the CPO database of Figuie 22 for a cruise implementation. 

Figure 41 illustrates an alternative sample uAile from the secured rules 
25 database of Figure 23 for a cnuse implementation. 

Figure 42 is a flow chart describing an exemplary post-sell multi-bind 
process which may be implemented by the CPO management central iKrver of Figure 
22. 

Figure 43 illustraies a sample table from the excluded operator 
30 counteroffer database which may be implemented by the CPO management central 
server of Figuie 22 in oonjunction with the flow chart of Figures 44a and 44b. 
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Figuies 44a and 44b, ccrilcctively, are a flow chart describing an 
exemplary excluded seller CPO evaluation process which may be implemented by the 
CPO management central server of Figure 22. 

Figure 4S is a schematic block diagram illustrating a package 
S conditional purchase offer (CPO) management system In accordance with one 
embodiment of the present invention. 

Figure 46 is a schematic block diagram of the exemplary central 
controller of Figure 4S. 

Figure 47 is a schematic block diagram of the exemplary secured server 

10 of Figure 45. 

Figure 48 is a schematic block diagram of an exemplary buyer or seller 
interface of Figure 4S. 

Figure 49 illustrates a sample table from the buyer database of Figure 46. 
Figure SO illustrates a sample table from the seller database of Figure 46. 
IS Figure S I illustrates a sample table from the package CPO databa.<%c of 

Figure 46. 

Figure S2 illustrates a sample table from the component CPO database of 

Figure 46. 

Figure S3 illustrates a sample table from the market price database of 

20 Figure 46. 

Figures S4a and 54b illustrate sample tables from the secured seller rules 
databa.sc of Figure 47. 

Figures 55a through 55c, collectively, arc a flov^ chan describing an 
exemplary package CPO posting process implemented by the central controller of 
2S Figure 46. 

Figures S6a through S6c, colleaively, are a flowchan describing an 
exemplary package CPO monitoring process implemented by the central controller of 
Figure 46. 

Figure 57 is a flow chan describing an exemplary component CPO rule 
30 evaluation process implemented by the secured server of Figure 47. 
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Figure S8A is a schematic block diagram illustrating a conditional 
purchase offer (CPO) mans^ement system in accoidaitce with one embodiment of the 
present invention. 

Figure S8B is a schematic block diagram illustrating a conditional 
S purchase offer (CPO) management system in accordance with an alternate embodiment 
of the present invention. 

Figure 59 is a peispective view of an illustrative telephone set utilized by 
the calling party of Figures S8A or S8B. 

Figure 60 is a schematic block diagram of a central server used by the 
10 CPO management system of Figure 58. 

Figure 61 illustrates a sample table from the customer database of Figure 

60. 

Figure 62 illustrates a sample table from the carrier database of Figure 

60. 

IS Figure 63 illustrates a sample table from the published rate database of 

Figure 60. 

Figure 64 illustrates a sample table from the CPO database of Figure 60. 

Figures 6Sa and 6Sb, collectively, are a flow chan describing an 
enemplaiy CPO management process implemented by the central server of Figure 60. 
20 Figures 66a and 66b, collectively, are a flow chart describing an 

exemplary IVRU process implemented by the central server of Figure 60. 

Figure 67 is a schematic view of a system according to one embodiment 
of the present invention. 

Figure 68 is a schematic view of a central controller used in the system 

25 of Figure 67. 

Rgure 69 is a schematic view of a remote user terminal used in the 
system of Figure 67. 

Figure 70 is a schematic view of a venue controller used in the system of 

Figure 67. 

30 Figure 7 1 a' is a table illustrating the contents of an event table used in the 

system of Figure 67. 
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Figure 71b is a table illustrating the contenis of a venue table used in the 
system of Figure 67. 

Hgure 71c is a table illustrating the contents of a customer table used in 
the system of Figure 67. 
S Figure 7 1 d is a table illustrating the contents of an offer table used in the 

system of Figure 67. 

Figure 71e is a table illustrating the contents of a transaction table used 
in the system of Figure 67. 

Figure 72a is a table illustrating the contents of a ticket table used in the 
10 system of figure 67. 

Figure 72b is a table illuiitTaiing'the conienLs of a teplacement ticket table 
used in the system of figure 67. 

Figures 73a-73g are flow diagrams depicting a method of submitting and 
accepting a guaranteed offer to buy an event ticket over the Internet according to one 
13 embodiment of the present invention. 

Figure 74 is a schematic illustration of a system for processing the .<iale of 
products provided in accordance with the present invention. 

Figure 7Sa is a schematic illustration of an embodiment of a central 
controller of the system of Figure 74. 
20 Figure 7Sb is a schematic illustration of another embodiment of a central 

controller of the system of Figure 74. 

Figure 76 is a schematic illustration of a borrower database of the central 
controller of Figures 7Sa and 7Sb. 

Figure 77 is a schematic illustration of a lender databa.sc of the central 
25 controller of Figures 75a and 7Sb. 

Figure 78 is a schematic illustration of an offer database of the central 
controller of Figures 7Sa and 7Sb. 

Figure 79 is a schemuic illusinition of a credit report database of the 
central controller of Figures 75a and 7Sb. ' 
30 Figure 80 is a schematic illustration of a collateral database of the central 

controller of Figures 7Sa and 7Sb. 
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Figure 81a is a schematic illustration of a response database of the 
central controller of Figure 75a. 

Figure 8 lb is a schematic illustration of a rule database of the central 
controller of Figure 7Sb. 
5 Figures 82a and 82b are flowdiarts showing a method for processing 

sales of a loan between a boirower tenninal and lender terminals. 

Figure 82c is a flowchart showing another method for processing sales of 
a loan between a boirower teiminal and lender terminals. 



10 Detailed Description of Preferred Embodiments 

The method and apparatus of one embodimcni of the present invention 
will now be discussed with reference to Figures I. 2. 3, and 4. In a preferred 
embodiment, the present invention includes central controller 20O, seller interface 300, 
buyer interface 400, and associated databases. The preseni invention receive.'! 
IS conditional purchase offers from buyers, makes them available for viewing by potential 
sellers, and allows sellers to bind them. Thus, a buyer is able to communicate his 
commitment to follow through on an offer to a seller, giving (he seller confldence that if 
he can produce the goods, the buyer has the ready capacity to pay. 

SYSTEM ARCHrrECTURE 
20 The system architecture of a first embodimcni of the apparatus and 

method of the present invention is illustrated with reference to Figures I through 4. As 
shown in Figure 1, the apparatus of the present invention comprises seller interface 300, 
central controller 200, and buyer interface 400 (collectively the "nodes"). Each node is 
connected via an Internet connection using a public switched phone network, .such a.s 
2S those provided by a local or regional telephone operating company. Connection may 
also be provided by dedicated data lines, cellular. Personal Communication Systems 
("PCS"), microwave, or satellite networks. Seller interface 300 and buyer interface 400 
are the input and output- gateways for communications with central controller 200. 

Using the above components, the present invention provides a method 
30 and apparatus to post conditional purchase offers, make them available to potential 
sellers, and allow sellers to bind the offers to form a legally binding contract. 
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As shown in Figuie 2. centra] controller 200 includes central processor 
(CPU) 205. cryptographic processor 210, RAM 215, ROM 220, payment processor 230, 
clock 235, operating system 240, network interface 245, and data storage device 250. 

A conventional personal computer or computer workstation with 

5 sufTicient memory and processing capability may be used as central controller 200. In 
one embodiment it operates as a web server, boih receiving and transmitting CPOs 100 
generated by buyers. Central controller 200 must be capable of high volume transaction 
processing, performing a significant number of mathematical calculations in processing 
communications and database searches. A Pentium micraprocessor such as the 100 

10 MHz PS4C, commonly manufactured by Intel Inc., may be used for CPU 205. This 
processor employs a 32-bit aichitecturc. Equivalent processors include the Motorola 
120 MHz PowerPC 604 or Sun Miciosystcm s 166 MHz UluaSPARC-I. 

An MC68HCI6 microcontroller, commonly manufactured by Motorola 
Inc., may be used for cryptographic processor 210. Equivalent processors may also be 

15 us&d. This microcontt^ller utilizes a 16-bit multiply-and-accumulate instruction in the 
16 MHz configuration and requires less than one second to perform a S 12-bit RSA 
private key operation. Cryptographic processor 210 supports the authemk:ation of 
communicatiorei from both buyers and sellers, as waU as allowing for anonymous 
transactions. Cryptographic processor 210 may also be configured as pan o! CPU 205. 

20 Other commercially available specialized cryptographic processors include VLSI 
Technology's 33MHz 6868 or Semaphore Communications' 40 MHz Roadrunncr284. 

Refening again to Figun: 2, payment processor 230 comprise!! 
conventional microprocessors (such as the Intel Pentium), supporting the transfer and 
exchange of payments, charges, or debits, attendant to the method of the apparatus. 

21 Payment processor 230 may also be ctmfigured as part of CPU 20S. Processing of 
credit card transactions by payment processor 230 may be supported with commercially 
available software, such as the Secure Webserver manufactured by Open Market. Inc. 
This server software transmits credit card numbers electronically over the Internet to 
servers located at the Open Market headquarters where card verification and processing 

30 is handled. Their Integrated Commerce Service provides back-office services necessary 
to run Web-based businesses. Services include on-line account statements, order-taking 
and credit card payment authorization, credit card settlement, automaied sales tax 
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calculations, digital receipt generation, account-t>ased purchase tracking, and payment 
aggregation for iow-priced services. 

Data storage device 250 may include hard disk magnetic or optical 
storage uniu, as well as CD-ROM drives or flash memory. Data storage device 2S0 
5 contains databases used in the piocessing of transactions in the present invention, 
including buyer database 255, seller database 260, CPO database 265, counteroffer 
database 267. seller response database 270, purchase confirmation database 275, 
contract detail database 280, payment database 285, cryptographic key database 290, 
and audit database 29S. In a prefened embodiment database software such as Oracle?. 
10 manufactured by Oracle Corporation, is used to create and manage these databases. 
Data storage device 230 also stores information pertaining to buyer account 297, seller 
account 298, and escrow account 299. 

Buyer database 2SS maintains data on buyers with fields such as name, 
address, credit can! number, phone number, ID number, social security number, 
IS electronic mail address, credit history, past system usage, public/private key 
information, etc. This infoimation is obtained when the buyer first registers with the 
systent, or immediately prior to posting his fiist CPO 100. Buyer database 2SS also 
contains the ttacUng number of each CPO 100 generated by the buyer, and the tiacking 
number of each seller response 1 10 and counteroffer 140 directed to the buyer); CPOs 
20 100. 

Seller database 260 maintains data on sellers with fields such as name, 
contact information, public/private key infoimation, payment preferences, type of 
business, and goods sold. Contact Information comprises a phone number, web page 
URL, bulletin board address, pager number, telephone number, electronic mail address. 

25 voice mail address,' facsimile number, or any other way to contact the seller. Upon 
registration, the seller may be requited to demonstrate evidence of ability to deliver on 
boimd CPOs 100. An airline, for example, might submit a listing of the city pairs they 
service sa that cenu-al coniraller 200 can quickly determine whether the airline is 
capable of satisfying a given CPO lOO. 

30 CPO database 265 Hacks all CPOs 100 with fields such as status, 

tradung number, date, time, subject, price, expiration date, conditions, and buyer 
identification number. This database is valuable in the event of disputes betweim buyers 
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and sellers regarding payment, because details of the contract can be produced. CPO 
database 265 may also store bond certificate 172. 

Counteioffer database 267 tracks all counteroffers 140. The structure of 
this database is identical to CPO database 26S, except for the addition of a field for CPO 
5 tracking number that allows counteroffer 140 to be correlated with a particular CPO 
100. 

Seller response database 270 tracks all seller responses 1 10 with Ticlds 

such as seller name, seller ID number, date, time, seller response tracking number, and 

associated CPO tracking number. 
10 Purchase confirmation database 275 tracks the messages sent to the 

buyer and teller confirming completed transactions (bound contracts). Fields include 

buyer name, buyer ID number, seller name, seller ID number, purchase confirmation 

Racking number, and associated CPO tracking number. 

Contract detail database 280 contains form background provisions for 
IS inclusion in CPOs 100. These form provisions effectively fill the gaps between 

conditions specified by the buyer, specifying the generic contract details con:imon lo 

most CPOs 100. 

~ Payment database 285 tracks all payments made by the buyers with 
fields such as buyer name, buyer ID number, amount of payment-, and associated CPO 
20 tracking number. This database may also store credit card numbers of buyers. 

Cryptographic key database 290 facilitates cryptographic functions, 
storing both symmetric and asymmetric keys. These keys are used by cryptographic 
processor 210 for encrypting and decrypting CPOs 100, seller responses 1 10, purchase 
confirmations 120. counteroffers 140. and buyer responses ISO. 
75 Audit database 29S stores transactional information relating to the 

posting of CPOs 100, allowing it to be retrieved for laser analysis. 

Buyer account 297 tracks all information pertaining to the buyers 
account with fields such as buyers name, bank and credit account numbers, and debit or 
credit transactions. This account may be a pointer to account data stored at the buyer's 
30 bank. 
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Seller account 298 tracks all information pertaining to the seller's 
account with fields such as seller^ name, bank and credit account numbers, and debit or 
credit transactions. Buyer payments for CPOs 100 may be sent to this account. 

Escrtiw account 299 is an account that temporarily holds buyer funds 
S before they arc placed in seller account 298. 

Network interface 243 is the gateway to communicate with buyers and 
selleis through respective buyer interface 400 and seller interface 300. Conventional 
internal or external modems may serve as network interface 245. Network interface 24S 
supports modems at a range of baud rates from 1200 upward, but may combine such 
10 inputs into a Tl or T3 line if more bandwidth is required. In a preferred embodiment, 
network interface 243 is connected with the Internet and/or any of the commercial on- 
line services such as America Online, CompuServe, or Pi«digy. allowing buyers and 
sellers access from a wide range of on-line connections. Several commercial electronic 
mail servers include the above functionality. NCD Software msuiufaciures 
15 "Post.Office," a secure server-based electronic mail software package designed to link 
people and information over enterprise networks and the Internet. The product is 
platform independent and utilizes open standards based on Internet protocols. Vsem can 
exchange messages with enclosures such ns files, graphics, video and audio. The 
system also supports multiple languages. Allemativeiy, network interface 245 may be 
20 configured as a voice mail interface, web site, BBS. or electronic mail address. 

While the above embodiment describes a single computer acting as 
central controller 200, those skilled in the art will realize that the functionality can be 
distributed over a plurality of computers. In one embodiment, central controller 200 is 
configured in a distributed architecture, wherein the databases and processors ore 
2S housed in separate units or locaiitms. Some controllers perform the primary processing 
fimisions and contain at a minimum RAM, ROM. and a general processor. Each of 
these controllers is attached to a WAN hub that serves as the primary communication 
link with the other controllers and interface devices. The WAN hub may have minimal 
processing capability itself, serving primarily as a communications router. Those 
30 skilled in the an will appreciate that an almost unlimited number of controllers may be 
supported. This anangement yields a more dynamic and flexible system, less prone to 
catastrophic hardware failuies affecting the entire system. The trusted server 
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embodiment provides more details of such a distributed environment, describing 
operations server 160, trusted server 16S, and bonding agency 170. The hardware of 
these serveis would be configured Similarly to that described for central controller 200. 

Figures 3 and 4 describe seller interface 300 and buyer interface 400, 
5 respectively. In an exemplary embodiment they are both conventional personal 
computers having an input device, such as a keyboard, mouse, or conventional voice 
recognition software package; a display device, such as a video monitor; a processing 
device such as a CPU; and a network Interface such as a modem. These devices 
interface with central controller 200. Alternatively, seller interface 300 and buyer 
10 interface 400 may also be voice mail systems, or other electronic or voice 
communications systems. As will be described further in the following embodiments, 
devices such as fax machines or pagers ate also suitable interface devices. 

Referring now to Figure 3, there is described seller interface 300 which 
includes central processor (CPU) 305, RAM 315, ROM 320, clock 335. video driver 
l,^ 325, video monitor 330, communication port 340, Input device 345. modem 350, and 
data storage device 360. Cryptographic processor 335 and biometrtc device 355 may be 
added for stronger authentication as described later. A Pentium microprocessor such as 
the 100 MHz PS4C described above may be used for CPU 305. Clock 335 is a standard 
chip-based clock which can serve to timestamp seller response 1 10 or counteroffer 140 
20 produced with seller interface 300. 

Modem 350 may not require high-speed data transfer if most seller 
responses 1 10 and counteroffers 140 produced are text-based and not too long. If a 
cryptographic processor is required, the MC68HC 1 6 microcontroller described above is 
used. The structure of biomeiric device 355 will be described below in conjunction 
2} with the cryptographic authentication embodiment. 

Data stotage device 360 is a conventional magnetic-based hard disk 
storage unit such as those manufactured by Conner Peripheral.s. Message database 370 
may be used for archiving seller responses 110 and counteroffers 140, while audit 
database 380 may be used for recording payment records and communications with 
30 central controller 200. 

Refeoing now to Figure 4, there is described buyer interface 400 which 
includes central processor (CPU) 405, RAM 415. ROM 420, clock 435. video driver 
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425, video monitor 430, ciyptogr^hic processor 435, communication port 440, input 
device 44S, modem 4S0, and data storage device 460. All of these components may be 
identical to those described in Figure 3. 

There are many commercial software applications thaf can enable the 
5 communications required by seller interface 300 or buyer interface 400, the primary 
functionality being message creation and transmission. Eudora Pro manufactured by 
Qualcomm Incorporated, for example, provides editing tools for the creation of 
messages as well as the communications tools to route the message to the appropriate 
electronic address. When central controller 200 is configured as a web server, 
10 conventional communications software such as the Netscape navigator web browser 
from Neisc^ Corporation may also be used. The buyer and seller may use the 
Netscape Navigator biowser to transmit CPO 100. seller response 1 10 or counietoffers 
140. No proprietary software is required. 

ONLINE EMBODIMENT 
IS In one embodiment of the present invention, communication.s between 

buyeis and sellers take place via electronic networks, with central controller 200 acting 
as a web server. The buyer logs on to central controller 200, creates CPO 100, and then 
disconnects from the network. CPO 100 is made available to potential buyers by 
posting CPO 100 on the web page of central controller 200. Periodic maintenance is 
20 performed by central controller 200 to ensure that active CPOs 100 have not expired, 
and that the buyer has sufficient credit available to pay a seller who elects to bind CPO 
100. Seller responses 1 10 are transmitted electronically to central controller 200 which 
contacts the buyer to indicate that CPO 100 has been bound. Ctoual controller 200 
transfers credit card information to the seller as soon as CPO 100 is bound. 
2S With reference to Figure S, there is described the process by which the 

buyer formulates CPO 100. M step 500, the buyer logs on to central controller 200 
using buyer modem 450 of buyer interface 400, establishing a communication link. It 
should be noted that the buyer may be an individual, a corporation, a partnership, a 
government, or any other entity. In one embodiment, central controller 200 has a page 
30 on the World Wide Web. allowing the buyer to provide information through the 
interface of conventioiial web browser software such as Netscape Navigator, 
ntanufactured by Netscape, Inc. At step S IO, the buyer selects the subject of die goods 
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he wants to purchase by selecting from a list of possible subjects. As shown in box 515, 
subjects might include airline tickets, hotel rooms, lental cars, insurance, mortgages, 
clothing, etc. After the subject is selected, a form is displayed on video monitor 430 of 
buyer interface '400. This form is an eleclronic contract with a number of blanks to be 

5 filled out by the buyer, widj each blank representing a condition of CPO 100. 

At step 520, the buyer enters a description of the goods. A business 
traveler, for example, might want to fly from San Francisco to New York. The 
description of the goods might be two first class round-trip tickets between those city 
pairs, leaving May 7 and reluming May 12. There would be a place on the form for 

10 originating city, destination city, date of departure, date of return, number of tickets, 
class of service, etc. The buyer simply fills in the blanks. The buyer then adds other 
conditions at step 530. The buyer, for example, may only want a nonstop ticket on a 
flight arriving at the destination city before midnight. These conditions would be 
.similarly entered into CPO 100. As indicaed in box 535, conditions could include the 

15 provision that a flight must arrive before midnight, a hotel room must be non-smoking, 
or a rental car must not be a compact. Conditions are the teims of CPO 100. allowing 
the buyer to tailor CPO ICO for his specific needs. Conditions may also be based on 
other conditions. For example, one condition might slate that four out of five other 
specified conditions must be met Alternatively, eaich condition of CPO 100 could be 

20 given a point value, widi CPO 100 requiring only that conditions be satisfied up to a 
certain total point value. For example, the buyer may indicate that a window seat is 
worth two points, an aisle seat one point, and a nonstop flight four points, etc. CPO 100 
could require that ten "points" must be met in order to satisfy the conditions of CTO 
100. Conditions could also indicate that for twenty-four hours following the first 

2S attempted binding of CPO 100. other sellers may make offers to bind, with the original 
binding seller completing the contract only if no better offer has been received. 
Conditions could even be based on external events. For example, the buyer could create 
CPO 100 which offered to buy airline tickets only in the event that it was snowing in 
November in the destination city. 

30 At step 540, the buyer adds an expiration date to CPO 100, if desired. 

This allows a buyer to post CPO 100 without worrying that he will later be bound after 
his needs have changed. At step SSO, the buyer enters a price. In a. CPO 100 for a 
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rental car, for example, the buyer may enter a price of fifty dollars for a three-day rental. 
At step S60, the buyer attadies his name or a unique user ID number to CPO 100. This 
ID number is received from central controller 200 when the buyer registers for the 
service, or is chosen by the buyer and then registered with central controller 200 by 

5 phone. Central controller 200 maintains a database of buyer ED nutnbers in buyer 
database 255, and issues (or allows) only unique numbers. If less security is required, 
Che user^ telephone number could serve as the ID number since it has the advantages of 
being both unique and easily lemembered. If additional security is required, those 
procedures described in the cryptographic embodiment may be implemented. 

10 Once the above elements have been developed, the buyer transmits them 

to central controller 200 at step 570. The buyer does this by clicking on a "send" button 
located on the screen in which he entered the terms of CPO 10Q. At step 580. 
boilerplate legal language is added to the components of CPO 100 to form a complete 
CPO 100. The legal language is pulled from contract detail database 280 thai stores a 

IS plurality of paragraphs. These paragraphs arc linked together with the above contract 
elements to form a complete CPO lOO. The only element missing which prevents CPO 
100 from being recognized as a legitimate contract is the name and signature of the 
seller. 

Instead of a World Wide' Web-based interface, buyers may also transmit 
20 CPO 100 data via electronic mail, voice mail, facsimile, or postal mail transmissions. 
With voice mail, (he buyer calls central controller 200 and leaves CPO 100 in audic> 
form. These CPOs lOO nay be transcribed into digital text at central controller 200, or 
made available to potential setters in the same audio format. In a postal mail 
embodiment, central controller 200 acts more like a router, directing CPOs 100 to the 
2S potential sellers, creating multiple copies of CPO 100 if necessary. CPO 100 may also 
be posted to bulletin boards or web pages operated by central controller 200. Central 
conirolier 200 supports a plurality of transmission methods, allowing for a wide variety 
of formats of CPOs 100. Some formats may be changed, however, before further 
processing by central controller 200. CPOs 100 transmitted by mail in paper form, for 
30 example, may be scaimed-in and digitized, using opfical character recognition software 
to create digital text. These embodiments flre more fiiUy described in the off-line 
embodiment described later. 
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Referring now to Figure 6, CPO 100 is received and checked to see that 
sufficient credit is available to cover the stated price of CPO 100, before CPO 100 is 
" made available to potential sellers. At step 600, central controller 200 extracts price and 
expiration date information from CPO 100. At step 610, payment processor 230 

5 submits a pre-autliorization of the price of CPO 100 to the credit card clearinghouse. 
This serves to "lock up" a portion of the available credit on the buyer's credit card 
preventing him from using up this credit while CPO 100 is still active. At step 620, the 
credit card clearinghouse responds to the pre-authorization, indicating whether 
sufficient credit is available. If sufficient funds are not available to cover the price of 

10 CPO 100, another credit card number is requested from the buyer at step 630. Once an 
additional credit card number has been transmitted, central controller 200 then 
resubmits the pre-authorization at step 610. At step 640. the expiration date of CPO 100 
is checked to see if it has already expired. If it has expired, CPO 100 is rejected at step 
6S0 and returned to the buyer. If CPO 100 has not yet expired, it is accepted at step 

IS 660. 

Referring now to Figure 7, there is illustrated an embodiment in which 
CPO too is activated and made available to potenUal sellers. At step 700. a unique 
tracking number is added to CPO 100. Central controller timestamps CPO tOO at step 
710, and then stores CPO 100 in CPO database 265. CPO database 265 contains a 

20 record for each CPO 100, and includes fields such as status, subject, tracking number, 
limestamp, description of goods, price, expiration date, conditions, and buyer ID 
number. The status field has values of "pending," "active," "expired," and "completed." 
A status of "pending" means that the CPO is not cunently available to potential sellers. 
Either it is still being processed by central controller 200, or it has been temporarily 

23 suspended by the buyer. An •active" CPO 100 is available to potential sellers and can 
be bound. An "expired" CPO 100 can no longer be bound. CPOs 100 that have been 
bound by a seller have a status of "completed." 

After being stored at step 720. CPO 100 may go through a series of 
processing steps. One step, if necessary, is language translation, either creating a 

30 standard language that all CPO 1 00s must be written in. or translating to the language 
most appropriate for the sellers to whidt it will be sent. This translation is provided by 
language experts at ceiitral controller 200, or by automatic translation software such as 



25 



wo 98/10361 



PCT/US97/15492 



Systran Professional, manufactured by Systran Software. Twelve bi-ditectional 
language combinations are available, including English to/fhmi French, Italian, 
German, Spanish. Portuguese, and Japanese. Another step, if necessary, is to edit for 
spelling or grammatical errors. CPO 100 might also be reviewed for clarity. Any CPO 
5 100 with an unclear term or condition would be returned to the buyer for clarification. 
A buyer listing a destination city of "Chicago " might have CPO 100 ictumcd for 
clarification or collection. 

Referring again to Figure 7, the status of the database record for CPO 
100 is set to "active" at step 730. At step 740, the subject of CPO 100 is extracted from 
10 the subject field. At step 750, CPO 100 is posted in an appropriate subject area. This 
allows central controller 200 to display CPO 100 only to the most appropriate sellers. 
In a World Wide Web environment, central controller 200 has a web page for each 
possible subject area. Thus all CPOs 100 requesting airline tickets would be displayed 
on the airline ticket web page. This makes it much easier for potential sellers to find 
IS appropriate CPOs 100 they might want to bind as they can go right to the subject who.se 
goods they can provide. In an alternative embodiment, CPO 100 is electronically 
mailed to potential sellers, either individually or in groups. Potential sellers could elect 
to receive all CPOs ICQ, only those CPOs 100 in their subject area, or a subset of CPOs 
100 representing a particular condition. For example, a car rental company might 
20 request that all car lenlal CPOs 100 for luxury cars be sent to them. 

In an embodiment in which CPOs 100 are being transmitted to the seller, 
it is important to note that there are a number of hardware options for seller interface 
300. Suitable seller interfaces 300 include fax machines, personal digital assisunts 
(PDAs) with wireless connections, and beepers or pagers. For example, a rare coin 
2S dealer could instruct central controller 200 to beep him whenever CPO 100 appeared for 
Morgan Silver Dollars, providing details of CPO 100 over the beeper network, or 
informing the seller to log on to central controller 200 for further details. 

Referring now to Figure 8. there is illustrated a procedure for the 
maintenance of CPOs 100. At step 800, central contioller 200 searches CPO database 
30 26S. At Step 810, the expiration date field of each database record of CPO 100 is 
compared to the current date. If the expiration date of CPO 100 is earlier than the 
cunent date, the stanis of CPO 100 is changed to "expired" at step 820. At step 830, 
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payment processor 230 contacts credit card clearinghouse to verify that the buyer's 
credit card is still valid. If the card is not valid, the status of CPO 100 is changed to 
"expired" at step 840. The maimenance process is completed at step 850 once all 
"active" CPO database records have been examined. 
5 Figure 9 illustrates the process by which a potential seller selects CPO 

100. At step 900, the potential seller logs on lo central controller 200 using modem 350 
of seller interface 300. At step 910, the potential seller selects an appropriate subject 
area. For example, a large Chicago hotel that had just experienced the cancellation of a 
block of rooms for a convention might search in the hotel subject area in the hopes of 
10 finding a CPO 100 requesting a room in Chicago on those dates. At step 920. the 
potential seller browses the list of available CPOs 100 (i.e. those with a status of 
"active"). CPOs 100 may be listed with minimal detiuls, with additional infonnation 
available only if the potential seller is interested in binding CPO 100. A hotel CPO 100 
might be listed as "hotel-09/16/96-Chicago-single occupancy-S8S." A potential seller 
IS wanting more information about CPO 100 may request additional data at step 940. In 
one embodiment, each CPO 100 is hyperlinked to a separate web page that provides 
complete details. The potential seller clicks on CPO 1 00 and is immediately transferred 
to the page of supponing detail. This detail might include the required type of bed, 
fitness facilities, and restaurants. In another embodiment, CPO 100 is electronically 
20 transmitted directly to the seller, via electronic mail, fax, telephone, beeper, etc. 

Figures 10 and 11 illustrate the process by which CPO 100 is bound by u 
seller. At step 1000, the potential seller selects CPO 100 that he would like to bind, 
developing seller response 110 that represents his tnteniion to bind. At step 1010, 
central controller 200 receives seller response 1 10 from the potential seller. Central 
23 controller 200 then timestamps seller re<;ponse 1 10 and auiheniicaies the identity of the 
seller, as' well as verifying his probable capacity to deliver the goods. The timestamp 
allows central conirolier 200 to determine the first unconditional acceptance to be 
received. If two seller responses 1 10 are received within a few seconds of each other, 
the timestamp allows central controller 200 to decide which was received first. 
30 Alternatively, the timestamp may be appended to seller response 110 at the time it is 
tiansmitled from seller interface 300, using clock 33S of seller interface 300. 



27 



WO98a036I 



PCT/US97/15491 



Authentication of the seller's identity involves central controller 200 
extracting the seller ID from seller response 1 10 and loolcing up the seller's identity in 
seller database 260. Infotmation in jellcr database 260 then provides an indication of the 
seller^ ability to deliver the goods. Before a seller can bind CPO 100 for an airline 
5 ticket, for example, central controller 200 must authenticate that the seller is an airline. 
If necessary, central controller 200 may verify that the seller can provide the specific 
good requested. Rather than just verifying that the seller is an airline, central controller 
200 may verify that it serves the city pairs requested by the buyer. In another 
embodiment, the seller incorporates seller response 1 10 into CPO 100, signing CPO 100 
10 by adding an indication that the contract is agreed to. This indication could be a digital 
signaiuie, or could involve adding a symbol or indicia representative of the seller. 

Cential controller 200 then verifies the status of CPO 100 ai step 1030. 
determining whether or not the status of CPO 100 is "active" at step 1040. If CPO 100 is 
cunently "active," a unique tracking number is added to seller response 1 10 at step 
IS 1060. Central controller 200 dten stores seller response 1 10 in seller response database 
270 at step 1070. If the status of CPO 100 is not "active" at step 1040. seller response 
1 10 is refused by central controller 200 and transmitted back to the potential seller at 
step iOSO. 

In another embodiment, the seller transmits seller response 1 10 directly 
20 to the buyer ai step lOIO. The buyer nay then send seller response 1 10 in central 
controller 20O for verification and authentication, or he may choose to accept seller 
responiie 1 10 without verification and authentication. 

In Figure 1 1 , the payment process is begun at step 1 100 when the credit 
card number and approval code for the selected CPO 100 is transmitted to the seller. At 
3S step 1 1 10 CPO 100 is bound, turning CPO 100 into a legally binding contract between 
the buyer and seller. The binding process requires that the status of CPO 100 be 
changed to "completed," preventing subsequent sellers from being able to bind CPO 
100. The binding process also requires that the seller ID be added to CPO 100. At step 
1120. central controller 200 sends purchase confirmation 120 to the seller and then 
30 sends it to the buyer ai step 1 130. 

In another embodiment, niultipie sellers may bind CPO 100. In this case, 
CPO 100 may, maintain its status of "active" until a given number of sellers have 
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lesponded, and only then is the status of CPO 100 changed to "completed." For 
example, a raic coin dealer may post CPO 100 offering a hundred dollars for a specific 
type of coin. A condition of CPO 100 may stale that the offer is open to the first ten 
sellers to respond, allowing for ten bindable contracts. Another option is to open CPO 
S 100 to any number of bindings, or any number of bindings up to the funds available by 
the buyer. 

There are many methods by which the providers- of the system could 
derive a revenue stieam. In one embodiment, a flat fee is charged for every CPO 100 
submitted. There could also be flat fees that would cover any number of CPOs 100 over 
10 a given period of time, allowing buyers to subscribe to the service much as they would 
.subscribe to a newspaper. In another embodiment, central controller 200 calculates a 
discounted value of the price in which sellers receive only a percentage of the price of 
CPO 100. In another embodiment, advertisers pay lo have messages listed along with 
CPOs 100, supplementing the costs of operating the system. Altematively, the method 
I S and apparatus of the present invention may be employed without a payment feature. 

Hgure 12 illustrates the exchange of goods between buyer and seller. At 
step 1200, the seller transfers the specified goods to the buyer. This transfer coiild 
involve the delivery of physical goods as well as digital goods. Physical goods might 
include cars, jewelry, computer equipment, etc. Digital goods might include 
20 documents, tickets, access codes, etc. A hotel, for example, might transfer a 
confirmation number to the buyer, to be presented upon check-in at the hotel. At step 
1210. the buyer examines the delivered goods to see if they meet all conditions and 
terms of CPO 100. A buyer purchasing a hotel room, for example, would verify thai the 
room was for the correct dote and was in the correct city. At step 1220. if the goods do 
2S not meet the buyers conditions as described in CPO 100 the buyer contacts an arbiter at 
central comroiler 200 for dispute resolution. This process is described in more detail in 
the dispute resolution embodiment described later. At step 1240 the transaction is 
complete. 

PAYMENT PREFERENCES 
30 Figure 1 3 illustrates a protocol in which central controller 200 establishes 

buyer account 297. At step 1300, the buyer selects his preferred method of payment. 
Preferred m^hods might inclutie credit cards, personal checks, electronic funds transfer. 
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digital money, etc. At step 1 3 1 0, the buyer transmits payment data corresponding to his 
prefetred method of payment to central controller 200. As indicated by box 1315, such 
payment data might include credit card number or bank account number. These 
payment methods are meant to be merely illustrative, however, as there ate many 
s equivalent payment methods coiranonly known in the art that may also be used. If the 
buyer wants to pay by credit card, for example, payment data would include his credit 
card account number, expiration date, name of issuing institution, and credit limit. For 
electronic funds transfer, payment data include the name of the boyer's bank and his 
account number. At step 1320, cential controller 200 stores payment data and payment 
10 preferences in payment database 285. 

At step 1330, central controller 200 establishes buyer account 297 that 
either stores money transferred by the buyer or serves as a pointer to an account of the 
buyer outside the system. For buyers using credit cards, for example, buyer account 
297 contains the credit card number, expiration date, and name of issuing institution. 
IS Buyers could also transfer money to central controller 200 to be stored in buyer account 
297, which would operate like a conventional checking account. Central controller 200 
would send a check to the seller written on buyer account 297. Alternatively, central 
contioller 200 could elecitpnically move the funds directly from buyer account 297 to 
seiler account 298. At step 1340, central controller 200 contacts the bank or card issuer 
20 to confirm that funds are available. A buyer is thus unable to use a eredh card with no 
credit available to establish buyer account 297. 

The above protocols may be similarly applied to sellers, allowing for the 
creation of seller account 298. The primary difference being that seller account 298 is 
primarily used for deposits, with money flowing from seller to buyer in the ca.w of 
25 deposit returns or refunds when the buyer does not find the received goods acceptable. 
VeriHcation of funds available is therefore not as important for sellers. 

Although the on-line embodiment describes a protocol in which central 
controller 200 transmits credit card Information to the seller for processing, there are of 
course many payment protocols under which payment may be tfansferred from buyer to 
30 seller. In one embodiment, processing the credit card is performed by central conuotler 
200, not the seller. Central controller 200 looks up the credit card number of the buyer 
in payment database 285. This credit card number is transmitted to payment processor 
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230. Payment processor 230 contacts the credit card clearinghouse to get an 
authorization number. The billable amount appears on the credit card statement of the 
buyer in his monthly statement The clearinghouse posts this amount to seller account 
298. Central controller 200 updates payment database 285 to iifdicate that payment has 

S been made. Central contioller 200 could also arrange for payment to be made directly 
between buyer and seller by ptoviding payment information to each party. The buyer, 
for example, might receive the checking account number of the seller. Account 
information could also be embedded into CPO ICQ and seller response 1 10. allowing 
buyer and seller to complete payment once they each had a copy of CPO 100. 

10 Another method of payment involves procedures using digital cash. 

Central controller 200 looks up the buyer's electronic delivery address in payment 
datid>ase 28S. This address is transmitted to payment processor 230. with the digital 
cash being downloaded from the buyer. Central controller 200 updates payment 
database 28S to indicate that payment has been made. This address might be an 

15 electronic mail address if the digital cash is to be transferred by electronic mail, or it 
could be an Intemet Protocol address capable of accepting an on-line transfer of digital 
cash. This electronic delivery address is sent to payment processor 230. The digital 
cash is downloaded to seller account 298 or diiecdy to the seller. Central controller 200 
then updates payment database 285 to indicate that payment has been made. Using 

20 these digital cash protocols, it is possible for the buyer to inchide payment along with 
CPO 100 in elecuonic form. 

The practice of using digital cash protocols to effect payment is well 
known in the an and need not be described here in detail. For reference, one of ordinary 
skill in the art may refer to Daniel C. Lynch and Leslie Lundquisl. Digital Money. John 

2S Wiley & Sons, 1996; or Seth Godin, Presenting Digital Cash. Sams Net Publishing. 
1995. 

IXLAYED PAYMENT EMBODIMENT 
Although the on-line embodiment describes a protocol in which sellers 
receive payment imnoediately upon binding CPO 100, other embodiments may be 
30 implemented in which payment is delayed until the goods have been received by the 
buyer, or delayed until some predetermined date. Paitial payments and installment 
payments art also supported by'the system 
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Escrow account 299 allows payment to be delayed until the seller 
completes delivery of the goods, while at the same time ensuring that the buyer will in 
fact make payment Central controller 200 establishes escrow account 299 as a 
temporary holding account. When the seller binds CPO 100 at step i 1 10, funds are 
5 transferred from buyer account 297 to escrow account 299. Only after the goods have 
been received by the buyer are funds transferred from escrow account 299 to seller 
account 298. The buyer may transmit a digitally signed release message to central 
controller 200, authorizing the release of the escrowed funds to the seller. 

In another embodiment, the buyer makes a partial payment when CPO 
10 100 is bound, and then completes payment when the goods are received. The fraction 
of the offered price of CPO 100 to be paid upon binding is a condition of CPO 100 and 
is stored in payment database 28S when CPO 100 is bound. Central controller releases 
this portion of the funds at step 1 1 10, and then releases the remaining ponion after 
goods have been delivered at step 1200. The partial payment made upon binding may 
IS be non-refundable. This would allow a hotel, for example, to sell hotel room 
reservations that are cancelable on two days notice, with cancellations within the two- 
day period resulting in forfeiture of deposit. 

In yet another embodiment. CPO 100 describes the use of installment 
payments. The first payment is made when CPO 100 is bound, followed by regular 
20 payments as specified in the conditions of CPO 100. The dates at which paymenLs are 
to be made are stored in payment database 285. 

COUNTEROFFER EMBODIMENT 
In one embodiment of the present invention, sellers respond to CPO 100 
not by binding it, but by making a counteroffer with modified and/or additional 
25 conditions- An airline, for example, might view CPO 100 for a Hrst class ticket for five 
hundred dollars. The airline may be willing to sell for six hundred dollars, and thus 
want to develop and issue a counteroffer rather than electing to bind CPO 100. This 
counteroffer is similar to CPO 100 except that the buyer is binding the seller instead of 
the seller binding the buyer. The counteroffer is also directed to a specific party (the 
30 buyer), unlike CPO 100 that may be directed to a plurality of sellers. 

figure 18 illustrates the devetopment of counteroffer 140. At step 1800, 
the potential seller selects CPO 100 for vhiOt he wants to make a counteroffer. At step 
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1810, the seller prepares counteroffer 140 with modified conditions. The seller follows 
the same process that the buyer uses to generate CPO IQO (steps 500 through 580), 
selecting the conditions of counteroffer 140. Alternatively, the seller is presented with 
an electronic copy of CPO 100 and is allowed to edit those conditions that the seller 
S wants to change. For example, a car rental company might take the buyers request for a 
ten dollar per day luxury car and counteroffer with a twenty-dollar per day compact car. 
At step 1820, the seller attaches the tracking number of CPO 100 to counteroffer 140. 
Central controller 200 receives counteroffer 140 at step 1830, setting the status to 
"active." Central controller 200 then adds a unique tracking number to counteroffer 140 
to at step 1840. and stores it in counteroffer database 267 at step 1850. Central controller 
200 entracts the tracking number of CPO 100 attached to counteroffer 140 in order to 
find the buyer to whom counteroffer 140 is transmitted at step I860. 

Figure 19 Illustrates the process by which the buyer responds to 
counteroffer 140. At step 1900, the buyer decides whether or not to bind coumeroffer 
IS 140. If he does not bind, counteroffer 140 is transmitted back to the potential seller at 
step 1910. If the buyer does decide to bind, buyer response 1 50 is transmitted to central 
contioller 200 at step 1920. At step 1930, funds are removed from buyer account 297 
and placed in seller account 298. At step 1940, the status of counteroffer 140 is 
changed to "completed." Purchase confirmation 120 is transmitted to the .wller at step 
20 1950 and transmitted to the buyer at step I960. Procedures for the exchange of goods 
are completed as described in Figure 12. 

OFF-LINE EMBODIMENT 
In one embodiment of the present invention, buyers and sellers 
communicate in an off-line manner with central controller 200. Rather than sending 
25 electronic mail or using web-based servers, buyers and sellers use a telephone, fax 
machine, postal mail, or other off-line eommimication tool. 

A buyer may use a telephone, for example, to generate CPO 100. The 
buyer calls ceiitral controller 200 and is connected with an agent. The buyer provides 
the terms of CPO 100 such as subject, description of goods, conditions, expiration date, 
30 price, etc. The buyer also provides his buyer ID, password, or private key so diat 
cential contioller 200 can authenticate his identity. The agent puts this data into digital 
fonn by typing it into a terminal and then adds legal language to form CPO 100. CPO 
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100 is then transmiaed to central controller 200 where it is made available to potential 
sellers as described in the on-line embodiment. 

In an alternative embodiment, the buyer calls central controller 200 and 
is connected with a conventional Intetacdve Voice Response Unit (TVRU) vi^hich allows 

5 the buyer to enter some or all of die terms of CPO 100 without the assistance of a live 
agent. The buyer initially selects from a menu of subjects using the touch-tone keys of 
his phone, and then the call is either directed to a live agent specializing in that subject 
area, or the buyer is prompted for further terms of CPO 100. 

Potential sellers may also use a telephone to browse and bind CPOs 100. 

10 The potential seller calls central controller 200 and selects a subject. Central controller 
200 then converts the text of each CPO 100 into audio form, reading the entire list to the 
potential seller. At any time during the reading of CPOs 100, the potential seller may 
press a combination of keys on his telephone to select CPO 100 for binding. The seller 
enters seller ID number and is authenticated by central controller 200 prior to the 

IS binding of CPO 100. Potential sellers could also enter parameters before having the list 
of CPOs 100 read to them. An airline, for example, might request that all airline CPOs 
100 for more than eight bundled dollars be read, skipping any CPO 100 widi a lower 
price. 

- Buyers may also communicate with an agent at central controller 200 
20 through faxes or posul mail. The agent receives Ihe message and proceeds to digitizf it 
and form CPO 100 as described above. 

CRYPTOGRAPHIC AUTHENTICATION EMBODIMENT 
In the previous embodimenis, authentication of the buyer and seller 
involves checking the attached ID or name and comparing it with those stored in seller 
2S database 260 and buyer database 255. Although this procedure works well in a low 
security environment, it can be significantly improved dirough the use of cryptographic 
protocols. These protocols not only enhance Ihe ability to authenticate the sender of a 
message, but also serve to verify the integrity of the message itself, proving diat it has 
not been altered during transmission. A small airline, for example, could be prevented 
30 from binding CPOs 100 requiring peifomiance by a large carrier as their identity would 
not be authenticated. Encryption can also prevent eavesdroppeis from learning the 
contents of the message. A competing airline, for example, could be prevented from 
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leading any intercepted seller response 1 10 generated by another competitor. Such 
techniques shall be refeiied to generally as cryptographic, assurance methods, and will 
include the use of both syraraetric and asymmetric keys as well as digital signatures and 
hash algorithms. 

J The practice of using cryptographic protocols to ensure the authenticity 

of senders as well as the integrity of messages is well known in the ait and need not be 
described here in detail. For reference, one of ordinary skill in the art may refer to 
Bruce Schneier, Applied Cryptography, Protocols, Algorithms, And Souice Code In C, 
(2d Ed, John Wiley & Sons. Inc.. 1996). 
10 Figure 14 describes a symmetric key embodimenl in which the seller and 

" cemial controller 200 share a key. Thus both encryption and decryption of seller 
response 1 10 are performed with the same key. This encryption may be implemented 
with an algorithm such as DES (U.S. Government standard, specified in FIPS PUB 46). 
or with any of several algorithms known in the art such as. IDEA, Blowfish. RC4, RC2, 
15 SAFER, etc. The seller encrypts seller response 1 10 with his assigned symmetric key at 
step 1400; using cryptographic processor 310 of seller interface 300. The key may be 
stored in message database 370 or otherwise stored or memorized by the seller. The 
encrypted seller response 110 is then transmitted to cryptographic processor 210 of 
central controller 200 at step 1410. Cryptographic processor 210 exu-acts the seller ID 
20 from seller response 1 10 at step 1420 and looks up the symmetric key of the seller in 
cryptographic key database 290 at step 1430, decrypting seller response 1 10 with this 
key at step 1440. Cryptogiaphic key database 290 contains algorithms and keys for 
encrypting, decrypting and/or authenticating messages. At step 1450. if the resulting 
message is intelligible, then it must have been encrypted by the same key. 
2S auibemicating that the seller must have indeed been the author of seller response 1 10. 

This procedure makes it significantly more dinicult for an unauthorized 
seller to represent himself as a legitimate seller. Without cryptographic procedures, an 
unauthorized seller who obtained a sample seller response 1 10 from a legitimate seller 
would be able to extract the seller ID and then attach this ID number to unauthorized 
30 seller responses 1 10. When seller response 1 10 has been encrypted with a symmetric 
key, however, an unauthorized seller obtaining a sample seller response 110 only 
discovers the seller^ ID number, not the symmetric key. Without this key, the 
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unauthorized seller cannot create a seller response 1 10 that will not be discovered by 
central cantroUer 200, since he cannot encrypt his message in the same way that the 
authorized seller could. The symmetric key protocol also ensures that seller response 
1 10 has not been tampered with during transmission, since alteration of the, message 

5 requires knowledge of the symmetric key. An encrypted seller response 110 also 
provides the seller with more anonymity. 

Referring now to Figure 15, there is shown an asymmetric key protocol 
in which seller response 1 10 is encrypted with a private key and decrypted with a public 
key. Two such algorithms for this procedure are RSA and DSA; At step 1500, the 

10 seller encrypts seller response 1 10 with his private key using cryptographic processor 
310, transmitting seller response 110 to central controller 200 at step 1510. 
Cryptographic processor 210 extracts the seller ID at step 1520 and looks up the seller'^ 
associated public key in cryptographic key database 290 at step 1530, decrypting seller 
response 1 10 with this public key at step 1540. As before, if seller response 1 10 is 

IS intelligible then central controller 200 has authenticated the seller at step 1550. Again, 
unauthorized selleis obtaining seller response 1 10 before it was received by central 
controller 200 are not able to undetectably alter it since they do not know the private 
key of the seller. Unanthorized selleis woukl, however, be able to tead the message if 
they managed to obtain the public key of the seller. Message secrecy is obtained if the 

20 seller encrypts seller response 1 10 with his public key. lequiring the attacker to know 
the seller^ private key to view seller response 1 10. 

Figure 16 shows a cryptographic technique using digital signatures to 
provide authentication and message integrity. One such algorithm is DSA (Digital 
Signature Algorithm), the U.S. Government standard specified in FIPS PUB 186. As in 

25 the asymmetric protocol described above, each seller has an associated public and 
private key. The seller signs seller response 1 10 with bis private key at step 1600 with 
cryptograjdiic processor 310 and transmits it to central controller 200 at step 1610. 
Central controller cryptographic processor 210 extracts the seller ID at step 1620 and 
looks up the seller^ public key at step 1630, verifying the signature using seller 

30 response 1 10 and the public key of the seller at step 1640. If seller response 1 10 is 
intelligible, then central controller 200 accepts seller response 1 10 as authentic at step 
I6S0. 
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Refening now to Rgure 17, there is described a cryptographic technique 
using message authentication codes for verifying the authenticity and integrity of seller 
response 110. In the hash protocol of the present invention, the seller and central 
controller 200 share a synunetric key, which the seller includes in a hash of seller 

5 response 110 at step 1700. In the hash protocol, a one-way function is applied to the 
digital representation of seller response 1 10. generating a code that acts much like the 
fingerprint of seller response 1 10. Any of the MAC algorithms, such as RIPE-MAC, 
IBC-Hash, CBC-MAC, and the like may be applied in this application. After 
transmitting seller response 110 to central controller 200 at step 1710, cryptographic 

10 processor 210 extracts seller ID from seller response 110 at step 1720. Then 
cryptographic processor 2 1 0 looks up the seller's symmetric key at step 1 730 and hashes 
seller response 1 10 with this symmetric key at step 1740, comparing the resulting hash 
value with the hash value attached to seller response 1 10. If the values match at step 
1 750. the integrity of seller response 1 10 is verified along with the authenticity of the 

15 seller. 

Although cryptographic techniques can provide greater confidence in the 
authenticity of seller response 1 10. they are useless if the seller^ cryptographic keys are 
compromised. An atiadwr obtaining the symmetric key of another seller is 
indistinguishable from that seller in the eyes of central controller 200. There is no way 

20 to know whether the seller was the true author of seller response 1 10. or an attacker 
with the right cryptographic keys. One way to solve this problem (known as undetected 
substitution) is to use biometric devices such as a fingerprint reader, voice recognition 
system, retinal scanner and the like. These devices incorporate a physical attribute of 
the seller into seller response 1 10. which is then compared with the value stored in seller 

25 database 260 at central controller 200. In the present invention, .such devices attach to 
seller imeiface 300. 

Fmgeiprint verification, for example, may be executed before the 
creation of seller response 1 10. during the generation of seller response 1 10 in response 
to prompts from central controller 200, at some predetermined or random times, or 

30 continuously by incorporating the scanning lens into seller interface 300 such that the 
seller, is required to maintain his finger on the scanning lens at all times for continuous 
veiification while seller response I ID is generated. 
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An example of such an identification device is the FClOO 
FINGERPRINT VERIFIER available from Staitck, a Taiwanese company. The FC 100 
is'readily ada{»able to any PC via an interface card. The fingeiptint verifier utilizes an 
optical scanning lens. The seiUer places his finger on the lens, and the resulting image is 

S scanned, digitized, and the data compressed and stored in memory. Typically, a 256- 
byte file is ail that is required. Each live-scan fingerprint is compared against the 
pieviously enrolled/stored template, stored in data storage device 360. If the prints do 
not match, the cryptographic algorithms executed by cryptographic processor 335 may 
prevent the seller from generatbig a seller response 1 10. 

10 In a voice verification embodiment, the seller's voice is used to verify his 

identity. This embodiment has, the advantage of not requiring the use of any specialized 
hardware since it can be implemented over a standard phone connection. The seller^ 
identity is verified at central computer 200. The process of obtaining a voice-print and 
subsequently using it to verify a person's identity is well-known in the art, and therefore 

IS need not be described in detail herein. One of ordinary skill in the art may refer to 
SpeaUEZ, Inc. for voice tdentification/verification technology. Conventional speaker 
identification software samples the seller^ voice. This sample is stored at central 
controller 20O in seller database 260. Each time the seller wants to transmit seller 
response 1 10 to central controller 200, he is required to call central controller 200 and 

20 speak into the phone at the prompt for a voice sample. If this sample matches that 
stored in seller database 260, the seller is provided a password which is incorporated 
into the digital signatuie appended to seller response 110. Any seller response 1 10 
received without an appropriate voice match password is not accepted. The voiceprint 
may also be stored in a database within data storage device 360 of seller interface 300. 

2S to verify the seller's identity locally piior lo allowing seller response 1 1 0 to be created. 

Although the above ciyptogtaphic and biometric protocols describe the 
au^encicalion and validation of seller response 1 10, they tttay be equally applied to the 
authentication and validation of CPO 100, counteroffer 140, buyer response 150, 
purchase confirmanon 120. or any other message or communication between buyers, 
30 sellers, and cefiiral contnller 200. 
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ANONYMOUS TRANSACTIONS EMBODIMENT 
As mentioned previously, the present invention provides for the 
anonymity of both buyers and sellers. Such anonymity is accomplished by eliminating 
all references to the names of the individuals for all transactions. A buyer, for example. 

5 would include his ID in CPO 100 rather than his name, preventing the seller receiving 
CPO 100 from discovering the buyer's identity. This is desirable if the buyer were a 
biotech firm that did not want rivals to know the type of lab equipment that the 
company was looking for. 

In a similar manner, sellers may also want to keep their identity a secret. 

10 An airline might not want the public to know that they are heavily discounting fares 
between certain cities. 

Although using ID numbers can provide anonymity, both for buyers and 
sellers,, there are a number of potential weaknesses. First, if the database of ID 
numbers, stored in buyer database 2SS or seller database 260, and their respective 

IS. buyers/sellers is compromised, anonymity is destroyed since the message sender can be 
looked up in buyer database 255 or seller database 260. To prevent this, the ID numbers 
are encrypted with the public key of central controller 200. so that even if it Is stolen it 
is useless without the private key. 

Although we have described only one possible method Tor maintaining 

2(1 anonymity, there arc other equivalents. For example, if the embodiment included 
telephone messaging, the identity of the buyer and seller could be maintained uiiing 
conventional voice modification techniques. If CPO 100 or seller response 1 10 were in 
a paper form, the form could be scanned using optical character recognition and 
translated into digital form, discarding any information that could be found in the 

25 original document. 

TRUSTED SQIVER EMBODIMENT 
In one embodiment of the present invention, central controller 200 is 
separated into three distfnci elements: operations server 160, trusted server 165. and 
bonding agency 170. Each server performs a distinct task in the process of managing 
30 CPO 100. This separation makes it more diRicult for attackers to compromise the 
system, as they must defeat the security of three separate systems instead of one. As 
indicated in Rgure 20, the^ servers 'work in conjunction with buyer interface 400 and 
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seller interface 300. Operations server 160 has the task of posting CPOs 100, and 
accepts all transactions previously authenticated by trusted server 1 65. Trusted server 
165 authenticates the identity of buyers and sellers, while bending agency 170 verifies 
the ability of buyers to pay and the ability of seileis to deliver on bound CPOs 100. In 
5 this embodiment, each server type may be distributed over a number of servers. 

The following protocols describe the interactions of the three servers and 
assume the following: 

I . Everyone knows the public keys of operations server 160, trusted 
.lerver 1 65, and bonding agency 170. 
10 2. The buyer and potential seller have bond cenincates 172. as 

discussed below. 

3. Public keys can be used both for encryption and for signing. 
Before 0*0 100 is accepted by operations server 160, it must bear the 
digital signature of both tmsted server 165 and bonding agency 170. Because of this, 
IS CPO 100 contains two additional elements - a trusted server ID and a bond certificate. 

The trusted server ID is the ID number of (he trusted server 165 thai 
authenticated the buyer who crested CPO I DO. The "bond cettiricate" is a public key 
certificate, with the oenifter (bonding agency 170) specifying a set of valid dates for 
bond cenincate 172, a limit to the amount covered, and a set of additional conditioas. 
20 These additional conditions may require on-line checking of a revocation list, may 
specify operations serveikl60 and trusted server 165 to be used, etc. The private key 
corresponding to the public key certified is not known to bonding agency 170 -- only to 
the user. Knowledge of that private key is used as proof of identity for the bondholiler. 
(This allows buyer and seller anonymity in many cases, though of course, neither will 
25 be anonymous lo bonding agency 1 70 except in very special cases.) 

Bond oenincau 172 for the buyer will be referred to as BCB, while the 
corresponding public and private keys will be lefened to as PKB and SKB, 
respectively. 

CPO 100 is posted by an interaction between the buyer, trusted server 
30 165, and operations server 160. This pan of the protocol is possible with nothing iriore 
than encrypted e-mail transmitted among the parties. 
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Before CPO 100 may be posted, the buyer must get approval from 
trusted server 165. This is required so that both llie buyer and operations server 160 
know that trusted server 163 tbeyVe designated to decide whether or not the contract 
has been fulfllled is actually willing to accept CPO 100. Operations server 160 will not 
5 accept CPO 100 without a TRUSTED.ACCEPTANCE message as described below. 

The trusted server 165, in turn, will not issue a 
TRUSTED_ACCEPTANCE unless it is convinced that the buyerls CPO 100 is fresh 
(not a replay), and that the buyers ability to pay is guaranteed by bonding agency )70. 
The buyer must also be convinced that he is being issued a fresh 
10 TRUSTED_ACCEPTANCE. 

The protocol works as follows: 

1. The buyer forms 

UO = "REQUEST FOR TRUSTED APPROVAL" 
XO = UO. CPO. RO. Additional Terms 
IS . and sends to misted server 1 65 

MO = PKEPKA (XO. Sign SKB (XO)). 

2. Tnisicd server 165 resiponds with 

UI = "TRUSTED CPO CHALLENGE" 
20 Rl - a 160-bit random number 

XI =Ulhash(XO),Rl 
and sends to the buyer 

Ml = PKEPKB (XI.SignSKA (XI)). 

2S 3. The buyer responds to this with 

U2 = "BUYER CPO RESPONSE" 

X2-U2.hash(Xl) 
and sends to trusted server 1 65 

M2 = PKEPKA (X2. SignSKB (X2)). 



30 



4. Trusted server 163 responds with 

U3 = "TRUSTED CPO ACCEPTANCE" 
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T3 = Timestamp 

X3 = U3, hash (X2). T3, CPO 
and sends to the buyer 

M3 a PKEPKB (X3, SignSKA CX3)). 
The buyer stores X3 as TRUSTED_ACCEPTANCE. 



In order for opeiaiions server 160 to post CPO 100, it must be convinced 
that CPO 100 has a fiesh TRUSTED.ACCEPTANCE, and that it is guaranteed by 
bonding agency 170. This works as follows: 
10 I . The buyer fonns 

R0= random 160-bit number 
UO = "CPO SERVER SUBMISSION" 
XO = UO. RO. TRUSTED_ACCEPTANCE 
and then sends to opentions server 1 60 
IS MO = PKEPKS (XO. SignSKB (XO)). 

2. Operations server 160 receives MO and verifies it. If it's fresh 
(not a replay), and if operations server 160 is willing to post CPO 100. it forms 

Rl = a random i 60-bit number 
U 1 = "SERVER CPO CHALLENGE" 
20 Xl= 1,hash(X0).Rl 

and then encrypts and sends to the buyer 

Ml = PKEPKB (XI, SighSKS (XI)). 

3. The buyer forms 

U2 = "CPO RESPONSE TO SERVER CHALLENGE- 
25 and then .sends to operatioas server 1 60 

M2 = PKEPKS (X2. SignSKB (X2)). 

4. If this messaged signature verifies properly, then tqjeraiions 
server 160 posts the CPO. Operations server 160 forms 

U3 = "POSTED CPO RECEIPT" 
30 CPO = U3,hash(X2),CPO. 

It then sends to the buyer 

M3 = PKEPKB (CPO, SignSKS (CPO)). 
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At the end of this protocol, the buyer has a receipt to aclcnowledge that 
his CPO 100 has been posted, and operations server 160 is convinced that the holder of 
bond certificate 172 has just agreed to CPO 100. and has the apptoval of trusted server 
165. 

5 The potential seller has a bonding certificate 172 (BCP) of his own. 

Before he is allovired to browse CPOs 100 In real time (with the ability to bind them), he 

must go through a protocol. (CPOs 100 may be available to people who aren\ 

browsing, but nobody is allowed to bind CTOs 1 00 until they go through this piotocol.) 

The purpose of this protocol is to prove that the seller is guaranteed by bonding agency 
10 170 to be capable of delivering the required goods, and also lo decrease the 

connpuutionat load on operations server 160 by establishing a secret authentication key. 

Kp. All of this decreases the computational expense of allowing the potential seller to 

browse CPOs 100. 

1 . The potential seller forms 

IS RO = a random 1 60-bit number 

T =: a time range 

UO = "REQUEST FOR ACCESS TO BROWSE" 
XO = U0,R0,T,BCP 
and sends to operations server 160 
» MO = PKEPKS (XO. SignSKP (XO)). 

2. Operations server 160 decides whether to gram the potential 
seller access. If so, it forms 

Rl = u random 160-bit number 
Ul = "SERVER BROWSE-ACCESS CHALLENGE" 
25 XI =Ul.hasli(X0),Rl 

and sends to the potential seller. 

Ml = PKEPKP (Xl.SignSKS (XI)). 

3. The potential seller responds by forming 

U2 = "BROWSE-ACCESS RESPONSE" 
30 and sends to operations server 160 

M2 o PKEPKS (X2, SignSKP (X2)). 



43 



PCTA)S97/lS4n 



4. Operations server 160 verifies the signature, and then responds by 

forming 

U3 = "BD4DING KEY" 

Kp = a random secret key to be used for binding CPOs 

5 100. 

T = a time range (from first protocol message) 
X3 = U3.hash(X2),T,Kp 
and sends to the potential seller 

M3 = PKEPKP (X3. SignSKS (X3)). 
10 At the end of this protocol, the potential seller holds the secret shared key 

with which he is allowed to bind CPO 100, wilKin the lime limits specified in the 
message. The potential seller and operations server 160 are both convinced that they 
have interacted with one another in real-time, and operations server 160 knows that the 
potential sellcrVi capacity to deliver on bound CPOs 100 are guaranteed by bonding 
15 agency 170. 

As the potential seller browses CPOs 100, each is sent to him by 
operations ,servcr 160, authenticated under Kp, and including a random challenge to 
pievent replay attacks. When the potential seller wants to bind one, he forms an offer to 
bind CPO 100. and sends it, along with the hash of the authenticated CPO 100. 
2D authenticated under Kp. Operations server 160 is convinced thai this is a valid offer to 
bind CPO 100, and that it's happening in real lime. It responls by sending him 
BOUND_CPO. 

1 . Operations server 1 60 forms 
U0 = "CPO OFFER" 
25 RO = a random 1 60-bit number. 

XO = UO. RO, CPO description 
and sends the potential seller 

MO = PKEPKP (XO, AuthKp(XO)). 
(Note Uuit this step is repeated for each CPO 100 browsed.) 

30 
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The potential seller fornis 

U 1 = "CPO OFFER TO BIND" 
R1 a random 1 60-bit number 
XI = U 1 . hash (XO). Rl . Offer Details 

and encrypts anil sends to operations server 1 60 
Ml = PKEPKS (XI. AuthKp(Xl)). 



3. If the offer is acceptable to operations server 1 60, then it forms 
U2 = "SERVER BINDING OF CPO" 
10 T = timestamp 

X2 = U2, hash (XI), BCP, f , CPO, Offer Details and 
encrypts and sends to the potendal seller 

M2 = PKEPKP (X2, SignSKS (X2)). 

15 4. The potential seller stores X2, SignSKS (X3) as BOUND.CPO. 



The "Offer Details" field of BOUND.CPO specifies die conditions of 
CPO 100. In most cases, this will involve delivciing some goods in exchange for 
payment, possibly in the presence of an agent from trusted server 165. In some casjis, 
20 however, this will involve intermediaries, to preserve anonymity for the potential buyer, 
the seller, or both, it is important that the potential seller has the BOUND.CPO so that 
he can prove bis identity to the buyer or an intermediary with a simple challenge- 
response protocol 

This set of protocols describes one possible implementation of an 
23 infrasuuciure lo support CPOs 100. it is important to note that operations server 160. 
misted server 165, and bonding agency 170 can conceivably be the same entity. In this 
case, these protocols can be dramatically simplified. 

BARTER EMBODIMENT 
Not all transactions require the transfer of money from buyer to seller. In 
30 a batter transaction the distinction between buyer and seller disappears, resulting in a 
contract between a first party and a second pany. The first party posts CPO 100, and 
the second paity binds it Instead of getting cash, the second patty receives goods from 
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the first party. A first party who wanted to get lid of a motorcycle, for example, could 
post CPO too in which he offered to exchange the motorcycle for a first class ticket 
from New York to London. 

ARBITRATION PROTOCOLS 

5 Although the previous embodiments have described the delivery of 

goods from seller to buyer as the end of the process, there will inevitably be disputes 
arising from some transactions, requiring follow-up activity to resolve these disputes. 
The present invention can support dispute resolution in two ways. 

First, language can be built into every CPO 100 requiring that both 

10 parties submit to binding arbitration of all disputes, helping to avoid more costly and 
time consuming legal battles in a court of law. Additionally, liquidated damages may 
be set which specify damage amounts for particular infractions of CPO 100. 

Second, central controller 200 can support the aibitration process by 
providing an arbiter for each' dispute. Such arbitration might be required when goods 

15 shipped from the seller do not correspond to the conditions of CPO 100. A buyer 
seeking a non-stop airiine ticket, for example, might seek damages against a seller who 
delivered a ticket with one or more stops. Similarly, a business traveler whose CPO 100 
for a non-smoking hotel room mi^t seek damages from the hotel which bound the CPO 
with a smoking room. Instead of seeking damages, the buyer may seek replacement of 

20 the goods, such as another airline ticket that was non-stop. In an arbitration involving 
airline tickets, the buyer may submit a copy of the ticket to central controller 20O along 
with the tracking number of CPO 100, allowing the arbiter to establish whether or not 
the seller fulfilled the conditions of CPO 100. Sellers may also initiate arbitration 
proceedings if they havb shipped the goods and have not yet received payment from the 

2S buyer. 

In an alternative embodiment, transaction data can be sent toi third pany 
arbiters outside the system. Central controller 200 may send a copy of CPO 100, seller 
response 1 10, and purchase confirmation 120 to the arbiters. Cryptographic keys may 
also be provided to the aibiters if there are questions of authenticity or non-repudiation. 
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APPUCATIONS OF THE INVENTION 
In order to clarify the application of the piesent invention, the following 
' examples demonstrate potential needs of end users: 
CPO: Airline tickets 
S Four tickets needed 

From Chicago. OHare or Midway to Phoenix. 
Leaving on April 12 or 13 
Returning on April IS or 19. 
Any of the six largest coiiiers acceptable. 
10 Change of planes is acceptable if layover is less than 2 hours. 

Ill bind at $180 per ticket, excluding tax. 
CPO: Hotel accommodations 
Five nights lodging 

Arrive April 12 or 13, Depart April 18 or 19 
IS . Within 30 minutes drive time of downtown Phoenix. 

Double bed 
Non-smoking 

Hotels, motels or bed & breakfasts are acceptable 

Must be AAA approved or Mobil 2* or belter. 
20 [11 bind at $SS per night (excluding tax). 

CPO: New car purchase 

1997 Ford Taunu 

Must be in dealer stock 

GL package w/air conditioning 
23 AM/FM/Cassette (Slock ff 1 224-099) 

May have other options already installed 

Can be white, tan, green or maroon 

Musi have 100 miles or less, never titled. 

No dealer demo cats 
30 Deliveied to me no later than July 15, 1996 

Lorn pie-approval: Chase Manhattan #l220-998-887AD-2l 

nibindatS21.3S0 
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CPO: Car insurance 

1997 Ford Taums 

1 driver, age 40. male 

Reside in Ridgefleld, CT 

Drive to woitc 30 miles 

Collision included 

$S00 deductible 

Glass coverage included 

No speeding infractions in last 3 years 

No accident in past 3 yeais 

IMM liability umbrella 

Driveri! license#CT 1222-221-2298 

Canier must be rated A or better by AM Best. 

ni bind at $1,200 per year 
CPO: U.S. silver dollars 

1 8S6 Morgan 

Philadelphia mint mark 

Sealed in ANA packaging 

MS94 or better grade 

I will purchase up to 6 total 

Sellers may fulfill all or part of order 

111 bind at S22S each 

Offer Administrator Coinworld, P.O. Box 1000. N.Y., N.Y. 
Mr. K. Smith 212-222-1000 
CPO: Industrial commodity 

My company wants to purchase 40 tons of steel 
Gtadel20 

Delivered FOB to NY, NY 
Qass 4 Slabs or Class 12 ingots 
Alloy RT- 1 2 or equivalent 
Deliver by August 1, 1996 
Maximum price known to Citibank 
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Fiist bid below maximum will bind 

Citibank to provide instant price verification 

I bid per supplier per day (ONilT) 

E-mail @ metals.blddesk4022Citi.com 
S Letter of Credit payment. Citibank 100-887-9877 

CPO: Credit Canl Application 

VISA Gold Card 

Credit line $S,000 

Interest rate 12% or lower 
10 III bind at S 10 per year 

Hnancial history available at htip://>www.provider/-shapiro23~ 
CPO: Reward for Return 

Briefcase lost with important computer disks inside 

Disks labeled RT-554 IBM 

Case is brawn leather, brass snaps. RL monogram 

Left on NYC subway. April 7. 1996 F Train. 

nibindatSSOO 

Provide lost & found receipt # to claim reward 
Offer Adminisirator: NYC Police Lost & Found 
20 Mr.K.Sniith 212-SSS-IOOO 



INDUSTRIAL APPUCABILrrY 
In view of the foregoing detailed description, it is evident that the in.stant 
Invention may be used to create one or more of the following systems, among others: 
2S - a system which allows a seller to meet the terms of (he purchase offer 

to bind the buyer to accept the seller^ fuinilment of that offer; 

- a system which allows the seller to be able to collect funds immediately 
upon his acceptance of the buyer* ternis as set forth in the purchase offer. 

- a system that allows for a trusted third-party administrator whose 
3D decision regarding the fulfillniem, adequacy or interpretation of any aspect of the 

piocess shall be binding on the parties; 
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- a system which allows the seller to receive part of his payment upon 
agreeing to the buyers purchase offer, and a subsequent payment upon delivery of the 
goods or services called for in ihe'buyer^ purchase offer; 

- a system which allows either buyers or sellers to remain anonymous up 
5 until such tiitie as an agreement is consummated and for buyers to remain anonymous 

even after the agreement is consummated by using the trusted third-party as a relay 
system for delivery of goods or services called for by the buyer's purchase offer 

- a system which ensures that buyers using the inventive system are not 
inundated with inquiries or acceptances from unqualified sellers; 

JO - a system which provides a system in which the identity of the buyer is 

authenticated along with the integrity of the buyers purchase offer. 

- a system in which the identity of the seller is authenticated in order lo 
deieimine the seller^ capacity to satisfy the conditions of the purchase offer 

- a system which allows sellers to submit aulhenticaiable counteroffers to 

IS the buyer: 

- a system in which eounteroffers may allow the buyer lo bind the seller 
to the counteioffer, subject to the authenticatable terms of that counteroffer; 

- a system which allows for delivery of digitally-based products such as 
certificates of insurance from the seller to the buyer according to the terms of the 

20 buyer's purchase offer and the cryptographic validation of such delivery; 

- a system which allows for purchase offers where more than one seller 
may biitd the buyer to toe purchase offer; and 

- a system which shows how all or part of the system can be pracdced 
- using non-electronic means such as printed media or advertisements in newspapers. 

2S In view of the aforementioned detailed description of the present 

inveniion, it is readily iqjparent that the present invention provides a method and 
apparatus for prospective buyers of goods or services to communicate a binding 
purchase offer globally to potential sellers, for sellers conveniently to search fot 
relevant buyer purchase offers, and for selleis to bind a buyer to a contract based on the 

30 buyers purchase offer. Additionally, the present invention can effecniate performance 
of the agreement between the buyer and seller by guaranteeing buyer payment for the 
purchase. Hie present invention is therefore a highly effective bilateral buyer-driven 
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commerce system which improves the ability of buyers to reach sellers capable of 
satisfying the buyer's purchasing needs and improves sellers' ability to identify 
interested buyers. 

In one embodiment of this invention, communications between buyers 

3 and sellers are conducted using an electronic network, and central controller. A buyer 
who wishes to make a purchase accesses the central controller located at a remote 
server. The buyer will then create a conditional purchase offer ("CPO") by specifying 
the subject of the goods he wishes to purchase, a description of the goods he wishes to 
obtain, and any other conditions the buyer requires. For enample, a typical CPO could 

10 specify that the buyer wants to purchase a block of four airline tickets from Chicago's 
OHare Airpon to Dallas, Texas, the tickets must be from any of the six largest U.S. 
cairiers. (he buyer is willing to change planes no more than once no long as the 
scheduled layover is less than two hours, and the buyer is willing to pay $ I SO per ticket, 
plus any applicable taxes. 

15 The buyer then attaches a user identification to the CPO and transmits 

the CPO to the central controller. Under the present invention, the CPO may be 
tran.^mined via numerous means inchiding a world-wide-web interface, electronic mail, 
voice mail, facsimile, or postal mail. Standard legal provisions and language are then 
integrated with the CPO lo Till in the gaps" of the buyer's purchase offer: Alteinatively, 

20 the CPO may be developed while the buyer i."; on-line with the central controller. 

Before communicating the CPO to potential sellers, the central controller 
authenticates the buyers identification number against a buyer database. The central 
controller may require that the buyer provide a credit card number and may also ensure 
that the buyer has sufficient credit available to cover the purchase price specified in ihe 

25 CPO by contacting the credit card clearinghouse. The central controller then assigns a 
unique tiacking number to the CPO and globally displays the CPO in a manner such 
that it is available lo be viewed by any interested potential sellers. CPOs may be 
displayed by subject category to make it easier for |K>tential sellers to identify relevant 
CPOs. Thus, a seller could log onto a web-site, for example, and see a listing of CPO 

30 subject categories. The seller could then choose a particular subject and have the ability 
to browse CPOs which correspond to that subject category. In one embodiment, the 
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seller may be required to provide qaalifications in order to view the CPOs of a given 
subject category. 

' If, after reviewing a particular CPO, a potential seller wishes to accept 
the CPO the seller communicates his intent to the central controller. The central 
S controller then timestamps the message from the seller and authenticates the identity of 
the seller and his capacity to deliver the goods sought by the buyer. The system then 
verifies that the particular CPO is still "active" and capable of being accepted. If a CPO 
is capable of being accepted only by one seller, it is "completed' when the Tirst qualified 
seller accepts it. Subsequent sellers will not be able to accept a "completed" CPO. If a 
10 seller accepts an active CPO, a unique tracking number is assigned to the seller^ 
acceptance. The acceptance is then stored in a database. The buyer and seller are now 
parties to a legally binding contract. 

In another embodiment, the cenffal controller manages the payment 
system between the buyer and seller atitomatically. Various methods of payment may 
15 be utilized by the invention, including credit cards, personal checks, electronic funds 
transfer, debit cards, and digital cash. The payment system nuy also involve the use of 
an escrow account associated with the buyer wherein funds -advanced by the buyer to 
cover the purchase of a desired good can be kept pending acceptance by a qualifled 
seller. Moreover, the timing of payment lo the seller can be varied. The seller can be 
20 paid immediately after the seller accepts the CPO or payment can be delayed until after 
the .seller performs his obligations under the contract. 

In yet another embodiment of the present invention, a seller is given the 
option to respond to a CPO by issuing a binding counteroffer with conditions different 
from the original CPO. The seller transmits the counteroffer to the central controller 
25 that then forwards the counteroffer to the buyer. The buyer is then given the option of 
accqxing the counteroffer and thereby binding the seller to a contract. 

Tlie present invention can also be practiced in off-line embodiments. 
Instead of using electronic rnail or web-based servers, buyers and sellers may 
communicate with the central controller via telephone, facsimile, postal mail, or another 
30 off-line communication tool. For example, buyers may use telephones to create CPOs 
(with or without die assistance of live agents) and potential sellers may use a telephone 
to browse and bind CPOs. 
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In another on-line enibodimEnt, cryptographic protocols are used to 
authenticate the identity of buyers and/or sellers and verify the integrity of buyer and 
seller communications with the central controller. Using cryptography and biometrics, 
the central controller can make it significantly more difricnic for unaathotized persons to 
s tamper with the system by passing themselves off as legitimaiB buyers or sellers or 
eavesdropping on system communications. 

Anonymity is another advantage of the present invention. For numerous 
privacy and competitive reasons, buyers and sellers often prefer not to have their 
identities revealed to the general public when engaging in commercial transactions. The 
10 present invention effectuates the anonymity of buyers and sellers through the use of 
identification numbers stored in a database .secured by the central controller. 

One embodiment of the present invention divides the functionality of the 
central controller into three components and embodies them in three separate servers: an 
operations server, a trusted server, and a banding agency. The trusted server 
15 authenticates the identity of buyers and sellers while the bonding agency verifies their 
ability to pay or deliver goods. The operations server posts the CPO, relying upon 
messages from the other two servers for validation. This conriguration allows for 
greater specialization of the servers. 

Another embodiment of the present invention does mm require a transfer 
20 of money from a buyer to a seller. Instead, the system may be used to consummate a 
contract involving an exchange of goods, services, or other non-monetary consideration. 

Finally, an embodiment of the present invention includes a mechanism 
for resolving disputes between buyers and sellens arising out of agreements 
consummated using the system. The parties may be requited in CPOs to stipulate to 
3S binding arbitration and may be assisted in the arbitration process by the central 
controller. The central controller may serve as an arfotttaioror may refer the dispute to a 
thinl-pany arbitrator for resolution. 

What the present invention accomplishes, which no previous system has 
done before, is literally to hang buyer money out on a clothesline for all sellers to sec. 
30 Attached to the money is a note describing what the seller has to agree to do in order to 
take the money down off the clothesline. There is no uncertainty or waste of time on 
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ttie part of the seller. He knows that if he can meet the condiuons set fonh by the buyer, 
he can immediately close the sale and get paid for it. No hassles. No negotiations. 

The invention also allows buyers to reach a targe number of leniotely 
located sellers who normally would not be able to afford to find the buyer, but who may 
S be able to provide the buyer with the exact deal the buyer desires. For instance, this 
might be the case for a car buyer who could precisely define the car and option 
packages he wanted for a specified price. The present invention allows such a buyer to 
Issue a binding purchase offer that is globally communicated to authorized dealers in the 
U.S.. Any one of those dealers could then decide whether or not to accept the offer. 
10 The buyers advantage is particularly significant when the sellers of products sought by 
the buyer have no inventory carrying costs, as is the case with insurance sales. 
Insurance buyers could use the present invention to cast a wide net to reach thousand.s 
of potential insurance sellers and potentially find a seller willing to satisfy the buyers 
specified purchase conditions. 
15 It is a goal of the present invention to provide a robust system thai 

matchM buyers' requirements with sellers capable of satisfying those requirements. The 
invention provides a global bilateral buyer-driven system for creating binding contracts 
incoiporating various methods of communication, commerce and security for the buyer 
and the seller. The power of a central controller to field binding offers from buyers, 
20 communicate those offers globally in a format which can be efficienily accessed and 
analyzed by potential sellers, effectuate peiformance of re<;ulting contracK. re.wlvc 
disputes arising from those contracts, and maintain billing, collection, authentication, 
and anonymity makes the present invention an improvement over conventional systems. 
AGENCY-BASED SELLERS 
2S The method and apparatus of another embodiment of the present 

invention, which permits the CPO management system to accept or reject a given CPO 
on behalf of cenain agency-based sellers who have delegated such authority to the CPO 
management system, will now be discussed witfi reference to Figures 21 through 40. 
Figure 21 shows a conditional purchase offer (CPO) management system 2100 for 
30 receiving conditional purchase offers from one or more customers or travel agents 21 10, 
hereinafter referred to as customer 21 10. and for evaluating the received CPOs against a 
number of CFO rales deflned by a plurality of sellers, such as aiiUnes 2120. 2130 or 
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cruise operators (not shown), to determine whether any seller is willing to accept a 
given CPO. As discussed further below, if a seller accepts a given CPO, the CPO 
management system 2100 binds the customer 2110 on behalf of the accepting seller 
2130, to form a legally binding contract. 
5 As used herein, a CPO is a binding offer containing one or more 

conditions submitted by a customer 2 1 10 for the purchase of an item, such as air travel, 
ai a customer-defined price. In the illustrative airline embodiment, the customer- 
defined conditions would include itinerary parameters, such as the origin and 
destination cities; acceptable dales and times of departure and return; and whether 
10 connecting flights or stopovers are acceptable to the customer. In addition, the 
parameters of a CPO may allow a customer to specify one or more preferred airline(s). 
flights, seat assignments, seat class, aircraft type, refund/change rules, or maximum 
layover time. In a cruise embodiment, the customer-defined condition.^ would also 
include itinerary parameters, such as the origin and destination cities; acceptable dates 
15 and times of departure and return, as well as one or more preferred cruise operaioni. 
ship type, cabin class, and dining preference. 

As discussed further below, a CPO rule is a set of lestrictions defined by 
a given seller, such as an airline, to define a combination of such rcstriciions for which 
the seller is willing to accept a predefined minimum price. In a preferred embodiment, 
20 the CPO rules are generated by the revenue managemeni system 2500 of the respective 
airline or cmisc operator. In alternate embodiments, the CPO rales may be generated by 
a yield management system, a profit managemeni system.' or any system that controls 
and manages inventory. 

As discussed more fully below in conjunction with Figures 25b and 39. 
25 the revenue management system 2500 will employ a CPO nilcs generation process 3900 
10 generate CPO rules by evaluating current inventory, pricing and revenue information, 
as well as hisioiicai patterns and external events, to forecast fiimre travel. Thereafter, 
the CPO lules'are utilized by the CPO management system 2100 to render a decision to 
either accept, reject or counter a CPO on behalf of a particular airline or cruise operator. 
30 According lo a feature of the present invention, the CPO rules are dynamic in nature and 
may be updated by a given airline or other seller, as necessary. 
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For example, a CPO rule for a given airline can specify that the airline 
will accept any CPO for travel between Newark, New Jersey (EWR) and Orlando. 
Florida (MCO) during the month of October,- 1997, provided (hat (i) the customer 
travels between Tuesday and Thursday, (ii) the tickets are booked within 21 days of 
5 departure, (tii) the price is at least $165 per ticket, (iv) K-class inventory is available on 
all flight segments of the customer's itinerary, and (v) there are at least two (2) 
passengers travelling together. 

Although the CPO management system 2100 is illustrated herein as a 
system for selling airiine or cniise tickets, the CPO management system 2100 could be 
Ift utilized to sell any good or service product, such as automobiles, insurance, computer 
equipment, or hotel accommodations, as would be apparent to a person of ordinary skill. 
For a more detailed discussion of a general CPO management system for selling such 
items, see U.S. Patent Application Serial No. 08/707,660. filed September 4, 1996, the 
parent application to the present invention, which is incorporated by reference herein, li 
IS is noted that in such alternate embodiments, the revenue management system 2500, 
discussed below in conjunction with Figuies 2Sa through 2Sc, may be embodied as an 
inventory management system or any other system utilized by the seller to esublish 
pricing and inventory information for the respective item. 

CPO MANAGEMENT SYSTEM 
20 As shown in Figure 21. the CPO management system 2100 preferably 

includes a CPO management central server 2200 and one or more .secured airline 
' serveis 2300. As discussed finther below in conjunction with Figure 23. each secured 
airline server 2300 may be associated with one or more airlines or cruise operators and 
each server 2300 stoics, among other things, the CPO rules defined by any associated 
25 sellers, such as the airline 2120. Each secured airline server 2300 may be remotely 
located from the CPO management cential server 2200. as shown in Figure 21. or may 
be integrated with the CPO management central server 2200. In one remote 
embodiment, the secured airline server 2300 associated with each airline or cruise 
operator may be physically located at a processing facility secured by the particular 
30 airlme or cruise opieiator. or at the physical location of a third party. In this manner, the 
airline or civise operator can evaluate CPO rules indqiendently. 
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The panicular location of the secured airline servers 2300 will dictate the 
nature of the information that is transmitted between the airlines 2120, 2130 or cruise 
operators (not shown) and the CPO management system 2)00. as would be apparent to 
a person of ordinary skill. - For example, if the secured airline servers 2300 are 
iotegjated with the CPO management central server 2200, or are otherwise remotely 
located from the respective airlines 2120, 2130 or cruise operators (not shown), then the 
respective airline 2120, 2130 or cruise operator will transmit the CPO rules to the 
location of the airline^ associated secured airline server 2300 for storage of the CPO 
rules and application of the CPO rules against each received CPO. Likewise, if the 
secured airiine servers 2300 arc physically located at the processing facility secured by 
the' associated airline or cruise operator, then the CPO management central server 2200 
will transmit the CPOs to each airhne or cruise operator for pmccssing and the uirline.>; 
or cruise operator will return the response for each CP-0 to the CPO management central 
server 2200. Thus, the CPO management system 2)00 can determine if one or more 
sellers accepts a given CPO by providing the CPO to each seller and receiving an 
acceptance or rejection, or by applying the CPO to the CPO rules to render a decision to 
either accept, reject or coumer a CPO on behalf of a panicular seller. 

The CPO rules contain sensitive infonnation. including price flexibility 
aild available capacity, which, if known to a seller's competitors or customers, could 
dramaticdiy impact the seller^ overall revenue structure. Thin, acconling to a feature 
of the present invention, the CPO rules are preferably securely stored by each airline 
server 2300, if necessary, to prevent one seller, such as airline 2120, from accessing, 
obtaining or altering the CPO rules i>f another seller, such as airline 2130. In one 
embodiment, the secured airline servers 2300 utilize computer security techniques, such 
as database access control mechanisms. In this nuuuier, the integrity and conftdeniiality 
of the CPO rules are maintained in the potentially hostile computing environment. 

In addition, according to a further feature of the invention, the CPO 
managenwnt system 2100 prevents custoineis 21 10 from submitimg multiple CPOs 
containing a progressively increasing price in order to identify the seller's defined 
miniimim price for a gjven fligbt or berth. For example, if the CPO will be binding 
upon the cnsiomer21 10 if accepted by any aiiiine 2120 or cmise operator, the customer 
2100 will be discouraged from "pinging" the CPO management system 2100 to ictentify 
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the seller's underlying price flexibility. In addition, the CPO management system 2100 
can limit the number of CPOs that any customer 21 10 can submit within a predefined 
time period. 

In alternate embodiments, the customer or travel agent 2110 can be 
5 charged a fee or a penalty if a ticket is not hooked when at least one airline has accepted 
the CPO or the CPO management system 2100 can evaluate a rating of said customer 
21 10 containing information regarcUng the likelihood that said customer 2110 will book 
a ticket corresponding to said CPO. For a more detailed description of a suitable rating 
system, see U.S. Patent Application Serial No. 08/8 1 1,349, filed March 4, 1997. entitled 
10 AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the 
present invention and incorporated by reference herein. In one embodiment, the 
evaluated rating comprises a ratio of bookings to purchase offers by the customer 21 10. 
In this manner, the airline or cruise operator can be confident that if the seller accepts 
the customer's offer, the customer will book the ticket withoul using the information to 
IS ascertain the seller's underlying level of price flexibility. The particular location of u 
given secured airline server 2300 may also impact the level of security measures that the 
associated airlinc(s) or cruise openttor(s) may desire for the sensitive CPO rules. For 
example, if a given secured airline server 2300 is dedicated to a single airline and is 
physically located at a processing facility secured by the associated airline, then the 
20 lespective airline may implement its own minimal security measures to control the 
processing of each CPO against its own CPO rules, if desired, and thereby maintain the 
integrity and confidentiality of the price-sensitive information incorporated into the 
CPO rules. If, however, a given secured airline server 2300 stores the CPO rules for a 
plurality of airlines or cruise operators and is remotely located from such airlines or 
23 cruise operators, then the importance of implementing computer security and databa.se 
access control mechanisms may be increased, as would be apparent to a penon of 
ordinary skill. 

As discussed further below, "each customer 2110 contacts the CPO 
management system 2100, for example, by means of telephone, facsimile, online access, 
30 e-mail, in-person contact or through a travel agent, and provides the CPO management 
system 2100 with the terms of their CPO. h is noted that each customer 21 10 may 
employ a general-purpose computer for communicating with the CPO inanagernent 
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system 2100. The general-purpose computer of each customer 2110 is preferably 
comprised of a processing unit, a modem, memory means and any software required to 
communicate with the CPO management system 21 CO. 

Once the terms of the CPO have been received by the CPO management 
5 system 2100, the CPO management central server 2200 will execute a CPO 
management process 3600. discussed below in conjunction writh Figures 36a through 
36c. to compare the received CPO against the CPO rules of each airiine or cruise 
operator. As a result of this comparison, the CPO is either accepted, rejected or 
countered, nieieafier, the customer 21 10 is notified of the response of the airlines or 
10 cruise opcrawrs to the CPO. If a seller accepts the CPO. or if the customer 2110 
accepts a counteroffer from a seller, a ticket is then booked by the CPO management 
system 2100 with the appropriate restrictions which meet the conditions defined by the 
customer 21 10. 

According to a funhcr feature of the present invention, the minimum 
15 requirements of a CPO are designed to discourage utilization of this system by business 
travelers or last minute travelers who are typically willing to pay full-fate. For example, 
business travelers will be discouraged if the CPO rules require a Saturday night stay or 
signiricant flexibility by the customer 21 10 on the time of both the departure and return 
portions of the customer^ itinerary. In this manner, business travelers, who are 
20 typically tmwilling to lose up to a full day at either end of their trip, will be di-icouragcd 
from purchasing such discounted tickets. Thus, the present invention permits airlines to 
All otherwise empty seats in a manner that stimulates latent and unfulfilled leisure travel 
demand while leaving underlying fare structures of the aiitines 2120, 2130 intact. 

Likewise, in embodiments where the CPO management system is 
35 utilized for the sale of any item, the minimum requirements of a CPO are preferably 
designed to discourage utilization of this system by customers who are typically willing 
to pay the full retail price. For example, when selling fashion items, CPO customers 
can be required to purchase fashions from the previous season. Similarly, the CPO rules 
can be designed to require the puichase of nuiltiple quantities of a given item, and 
30 thereby discourage use by consumers looking for one item, who are more likely to pay 
the full retail price. 
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In a preferred embodiment, the CPO management system 2100 may 
optionally access a central reservation system (CRS) 2400, discussed below in 
conjunction with Figure 24, to perform itinerary queries that will identify particular 
flights or berths which satisfy a given itinerary, and to make reservations. The central 
s reservation system (CRS) 2400 may be embodied, for example, as an existing 
conventional reservation system, such as Apollo. Sabre, System One or Worldspan. 

In addition, the CPO management system 2 1 00 could alternatively access 
the proprietary reservation systems (ARSs) 2150 of each airline or cruise operator to 
perform such itinerary queries and to make reservations with the respective airline or 
10 cruise operator. The airline reservation systems (ARSs) 2150 maintained by each 
airline 2120, are each essentially a subset of the central CRS 2400. Thus, in view of the 
overlapping functions and capabilities of the CRS 2400 and the propneiary reservation 
systems 2 ISO of each airline or cruise operator, the CPO management system 2100 
could access any of such systems to obtain requhed information, and the terms "CRS" 
1 J and "ARS" are used interchangeably herein. 

As shown in Figure 21, each airline 2120. 2130 or cruise operator (not 
shown), also has a revenue management system (RMS) 2500, discussed further below In 
conjunction with Figures 25a through 2Sc. The RMS 2S0O may be ennbodied as a 
conventional RMS, as modified herein to generate CPO rules and to otherwise allocate 
20 and price airline or cruise tickets for sale to CPO customers. 

Generally, the revenue management systetns (RMSs) 2500 arc utilized to 
optimize revenue per flight or berth, in a known mamer. An RMS performs seat or 
cabin inventory control by periodically adjusting nested booking limits ("buckets") for 
the various fare classes, in order to optimize the passenger mix and. thereby maximize 
25 the generated revenue. 

The CPO management system 2I0O. customer 2110, airlines 2120. 2130, 
cruise operators (not shown) and central leservation system 2400 (collectively, the 
"nodes") preferably transmit digitally encoded data and other information between one 
another. The communication links between the nodes preferably comprise a cable, fiber 
30 or wireless link on wfaicb electronic signals can propagate. Fbrexample, each node may 
be connected via an Intemet connection using a public switched tele^ione network 
(PSTN), such as those provided by a local or regional telephone operating company. 
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Alternatively, each node may be connecied by dedicated data lines, cellular. Personal 
Communication Systems ("PCS"), microwave, or satellite networks. 

Figure 22 is a block diagram showing the architecture of an illustrative 
CPO management central server 2200. The CPO management central server 2200 

5 preferably includes certain standard hardware components, such as a central processing 
unit (CPU) 2205, a random access memory (RAM) 2210, a read only memory (ROM) 
2220. a clock 222S. a data storage device 2230, and communications pons 2240. 2250. 
2260. The CPU 220S is preferably linked to each of the other listed elements, either by 
means of a shared data bus, or dedicated connections, as shown in Figure 22. 
10 The CPU 2205 may be embodied as a single commercially available 

processor, such as Intel^ Pentium 100 MHz P54C microprocessor. Motorola's 120 MHz 
PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UlltaSPARC-1 
microprocessor. Alternatively, the CPU 2205 may be embodied as a number of .<iuch 
ptocesiiois operating in parallel. 

15 The ROM 2220 and/or data storage device 2230 are operable to store one 

or more instructions, discussed further below in conjunction with Figure 36. which the 
CPU 2205 is operable to retrieve, interpret and execute. For example, the ROM 2220 
and/or data storage device 2230 preferably store processes to accomplish the transfer of 
required payments, charges and debits, between the airlines 2120, 2130 and customers 

20 2110. In panicular, as discussed below in conjunction with Figure 36c. the CPO 
managemem process 3600 preferably transmits the credit card information associated 
with a given customer 21 10 to the credit card issuer for payment, if a ticket is actually 
issued to the customer 2110. The processing of such accounting transactions are 
preferably .secured in a conventional manner, for example, using well-known 

2S cryptographic techniques. 

The CPU 2205 preferably includes a contiol unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackablc 
cache or a plmality of tegisteis, in a known manner. The control unit is operable to 
retrieve instructions from the dJita storage device 2230 or ROM 2220. The ALU is 

30 operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control inforraaiion. 
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As discussed further below in conjunction with Figures 26 through 29, 
respectively, the data storage device 2230 includes a customer database 2600, an airline 
database 2700, a flight schedule database 2800, and a CPO database 2900. The 
customer database 2600 preferably stores information on each customer of the CPO 

5 management system 2100, including biographical information and billing information, 
such as a credit card number. The airline database 2700 preferably stores information 
on each airline which is registered with the CPO management system 2100 to sell 
airiine tickets to CPO customers, including addiess and contact information. The flight 
schedule database 2800 preferably stores speciflc flight information for each O & D 

■0 Pair. Finally, the CPO database 2900 preferably contains a record of each CPO being 
processed by the CPO management system 2100. including the terms of the CPO and ~ 
the associated status. 

In addition, die data storage device 2230 includes a CPO management 
process 3600, discussed further below in conjunction with Figure 36. Generally, the 

15 CPO management process 3600 receives each CPO from a customer 21 10. compares 
the CPO against the CPO roles of each aMine 2120, 2130, and deieimines whether to 
accept, reject or counter the CPO on behalf of an airline. 

Hie communications port 2240 connects the CPO management cential 
server 2200 to the central reservation system (CRS) 2400 and the proprietary 

20 reservation systems (ARSs) 2150 maintained by each airline 2120. 2130. The 
communications pon 2250 connects the CPO management central server 2200 to 
individual customers and travel agents, such as the customer 2110, for example, by 
means of an Internet connection using the public switched telephone network (PSTN). 
The communications pott 2260 connects the CPO management central server 2200 to 

25 any remote secured airline servers 2300. The communications poru 2240, 2250, 2260 
each preferably mclude multiple communication channels for simultaneously 
establishing a plunlity of connections. It is noted that alihotigh the CPO management 
central server 2200 is illustrated as having three separate communication poits 2240, 
2250, 2260, the CPO management central server 2200 could alternatively be 

30 implemented with a single connection to an Ethernet network, which in turn provides 
the cennal server 2200 with a connection to the various noiles. 
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Figure 23 is a block diagram showing the architecture of an illustrative 
secured airline server 2300. As previously indicated, the CPO management system 
2100 may utilize one or more secured airline servers 2300, each supporting one or more 
airlines 2120, 2130. Each secured aTiline server 2300 preferably includes cenain 
5 standard hardware components, such as a central processing unit (CPU) 2303, a random 
access memory (RAM) 2310, a read only memory (ROM) 2320, a clock 2325, a data 
storage device 2330, and communications ports 2340, 2345. Each of these components 
may be identical to chose described above in conjunction with Figure22. 

As previously indicated, in one embodiment, the CPO rules may be 
10 stored in a secure database to maintain the integrity and confidentiality of the highly 
sensitive information included in each CPO rule. Thus, the secured airline server 2300 
preferably uses a secure database, such as the products commercially available from 
Oracle, Informix or IBM. 

As discussed further below in conjunction with Figures 30 through 32. 
15 respectively, the data storage device 2330 includes a secured airline rules database 
3000, a counteroffer rules database 3100, and a secured airline audit database 3200. 
The secured airline rules database 3000 preferably maintains the CPO rules for the one 
or more airlines associated with the secured airline server 2300. The counteroffer rules 
databaiie 3100 is preferably stored by each secured airline server 2300 to maintain a set 
20 of tolerances which may be utilized by the CPO management system 2100 to generate a 
counteroffer to a CPO on behalf of an airline, if the CPO Is within predefined tolerances 
of one or more restriction's associated with a given CPO rule. As previously indicated, 
the secured suriine rules database 3000 and the counleroffer rules database 3100 may be 
stored in an encrypted format to maintain the integrity and conTtdeniialiiy of the highly 
25 sensitive information included in the CPO rules. The secured airline audit database 
3200 preferably maintains an audit trail for each CPO that is processed by the CPO 
management system 2100. 

b addition, the data storage device 2330 includes an evaluation process 
3700 and an audit process 3800, discussed further below in conjunction with Figures 37 
30 and 38. respectively. Generally, the evaluation process 3700 is a sulvoucine executed 
by the CPO management process 3600, which icoeives a CPO and compares the CPO 
against the rules of one airline, such as the airline 2120, to g;eneiate a response on behalf 
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of the airline to the given CPO. The audit process 3800 is a subroutine executed by the 
CPO management process 3600 to maintain an audit (rail for each CPO that is processed 
by the CPO management system 2100. 

The'communications port 2340 connects the secured airline server 2300 
S to the CPO management central server 2200. The communications port 2345 connects 
the secured airline server 2300 to the associated airlines(s) 2120. The communications 
ports 2340, 234S preferably include multiple communication channels for 
simultaneously establishing a plurality of connections. 

CENTRAL RESERVATION SYSTEM 
10 Figure 24 is a block diagram showirtg the architecture of an illustrative 

central reservation system (CRS) server 2400. The CRS 2400 preferably includes 
certain standard hardware components, such as a central processing unit (CPU) 240S, a 
random access memory (RAM) 2410. a read only memory (ROM) 2420, a clock 242S, a 
data storage device 2430, and a communications pon 2440. Each of these components 
IS may be identical to those described above in conjunction with Figure 22. 

The ROM 2420 and/or data storage device 2430 are operable to store one 
or more instructions, for processing (I) flight information leceived from the airlines; (2) 
itinerary inquiries tegarding flight availability; and (3) ticket bookings, in a known 
nianncr, which the CPU 240S is operable to retrieve, interpret and execute. 
20 As discussed further below in conjunction with Figures 28, 33 and 34. 

respectively, the data storage device 2430 Includes a flight schedule database 2800, a 
pricing and restrictions database 3300, and a seat allocation database 3400. As 
previously indicated, the flight schedule database 2800 contains essentially the same 
flight information as the database of the same name which is stored by the CPO 
25 management central server 2200, namely, specific flight infomution for each O & D 
Pair. The pricing and restrictions database 3300 maintains pricing information and 
related restrictions for each fare class on a given flight offered by the airiines 2120, 
2130. The seat allocation database 3400 maintains available inventory information for 
each face class on a given flight offered by the airlines 2120, 2130. 
30 The communications pon 2440 connects the CRS 240O to the CPO 

management central server 2200 and to each airiine, such as the airlines 2120, 2130. 
The CRS 2400 prefisrabiy includes an electronic mail processor 24S0 for processing and 
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storing c-maii messages transmitted between the CRS 240O and the various customers 
21 10, airlines 2120, 2130 and the CPO tnanagement system 2100. 

REVENUE MANAGEMENT SYSTEM 
Figure 2Sa is a block diagram showing the architectute of an illustrative 

S revenue management system (RMS) 250O, as maintained by each airline, such as the 
airline 2120. As previously indicated, the RMS 2500 may be embodied as a 
conventional RMS, such as an RMS commercially available from Sabre Decision 
Technologies, as modifted herein to generate CPO rules and to otherwise allocate and 
price airline tickets for sale to CPO customers. In this manner, the RMS 2S0O makes a 

10 ponion of the inventory of an airline 2120 available for sale to CPO customers 2110. It 
is noted that the RMS for many airlines performs only the function of inventory 
allocation and does not incoiporatc a pricing function. In such cases, a separate system, 
such as a manual process, is utilized to price inventory that has been allocated by the 
RMS. In the illustrative embodiment disclosed herein, the RMS 2500 perfonn.s both the 

IS inventory allocation and pricing functions. 

The RMS 2300 preferably includes certain standard hardware 
components, such as a central processing unit (CPU) 2S0S, a random access memory 
(RAM) 2S10, a read only memory (ROM) 2520. a clock 2525, a data storage device 
2530, and a communications pott 2540. Each of these components may be identical to 

20 those described above in conjunction with Figure 22. 

The ROM 2520 and/or data storage device 2530 are operable to store one 
or more instniaions, for analyzing cunrem seating inventory and revenue, as well as 
historical panems, to allocate and price available seat inventory in an effoit to maximize 
revenue for the airiine, which the CPU 2405 is operable to retrieve, imeipiet and 

2s execiite. 

As discussed fiirther below in conjunction with Figures 33 through 35, 
respectively, the data storage device 2530 includes a pricing and restrictions database 
3300, and a seat allocation database 3400, which each contain essentially the same 
information as the databases of the same name stored by the CRS 2400, as well as a 
30 forecast and demand analysis database 3500. As previously indicated, the pricing and 
restriclioiis database 3300 maintains pricing information and related restrictions for each 
fare class on a given flig^ offered by the associated airline 2120. and the seat allocation 
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database 3400 maintains available inventory information for each fare class on a given 
flight offered by the associated airline 2120. The forecast and demand analysis database 
3500 contains infofmation on each selling price for each fare class for a given flight, 
and the forecasted demand at each selling price as established by the RMS 2500. In 

5 addition, the data storage device 2530 preferably includes a CPO rules generation 
process 3900, discussed below in conjunction with Figure 39, to generate CPO rules by 
evaluating current inventory, pricing and revenue infortnation, as well as historical 
pattens, to forecast future travel. 

The communications port 2340 connects each RMS 2500 to the CRS 

10 2400 and the CPO management system 2 100. 

Figure 25b illustrates the manner in which the RMS 2500 utilizes a 
number of databases and other tools in implementing a conventional pricing and 
allocation process and the CPO rules generation process 3900. The particular foimai 
and content of the Illustrative databases shown in Figure 2Sb arc disciLssed in detail 

13 below in conjunction with Figures 33 through 35. It is noted that' the conventional 
pricing and allocation process and the CPO rules generation process 3900 may be 
executed by the RMS 2500 iniUally when a flight is first added to the flight schedule, 
and then periodically to reallocate and price available invemoiy in response to demand 
and external events. 

20 Thus, when a flight is first added to the flight schedule of an airline 2 1 20. 

a record of the flight is preferably created by the airline reservation system 2 ISO in the 
flight schedule database 2800 with the appropriate itinerary information. In addition. 
iheRMS 2500 will perform a conventional pricing and allocation process in conjunction 
with the CPO rules generation process 3900. shown in Figure 39. lo initially populate 

25 the respective fields of the pricing and restrictions database 3300, seat allocation 
database 3400, and forecast and demand analysis database 3500 for the flight, as shown 
in Figure 2Sb. 

Generally, during the Initial pricing and allocation process for a given 
flight, the RMS 2500 attempts to maximize revenue by establishing a plurality of fare 
30 classes and allocating the numbn of seats and price assigned to each fare class. The 
initial seat allocation and pricing infotmation is stored in the seat allocation database 
. 3400 and the pricing and restrictions databalie 3300, respectively. The initial price for 
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each fare class and die forecasted demand is preferably stored in the forecast and 
demand analysis database 3500. In one embodiment, a separate fare class can be 
established by the RMS 2500 for selling tickets to CPO customers. Since tickets to 
CPO' customers ate generally sold at a discount, the RMS 2500 preferably only initially 
5 allocates seats to the CPO fare class which are forecasted to be empty or unlikely to be 
sold when the flight actually departs. As is well known, an airline can utilize a 
conventional RMS 2500 to predict, based on available historical data, whether or not 
there will be empty seats on a given flighu 

As shown in Figure 2Sb, the airline re.servation system (ARS) 2150 will 
to access the established pricing and restrictions database 3300 and seat allocation 
databa."ic 3400 to perform itinerary queries. In addition, a.s tickets are sold by the airline 
2120, the ARS 2IS0 will preferably decrement (he available inventory in the scat 
allocation database 3400. In this manner, the seat allocation database 34CO maintains an 
up-to-date representation of the available inventoiy on each flight. 
15 The RMS 2500 will continue to monitor the actual demand 2560 within 

each fare class relative to forecasted demand 2570, as illustrated by Figure 25c, 
dynamically reevaluating the inventory allocation and pricing of each fare class for a 
given flight in older to minimize the unanticipated excess inventory delta 2580. The 
RMS 2S00 monitors cunent actual demand information by retiieving detailed inventory 
20 data from the seat allocation database 34(X> or summaiy information from the foreca.<;t 
and demand analysis database 3500. In addition, the RMS 2S0O will utilize the 
historical demand information stored in the forecast and demand analysis database 3500 
for prior periods, which essentially provides a demand curve for each selling price of a 
given fare class on each flight. For example, when allocating and pricing inventory for 
2} a given flight, the RMS 2S0O may analyze demand trends for similar flights from 
previous relevant time periods, in a known manner. It is also noted that conventional 
RMSs typically respond to competitive forces and other external events, such as price 
wars or increased demand due to a large event, such as the Olympics, as shown in 
Figuie2Sb. 

30 According to a feature of the piesent invention, an airline 2120 can 

concct for forecasting etrots, if necessary, or other competitive forces which have 
produced unanticipated excess capacity 2S80, by releasing tickets for sale to CPO 
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customers. Due to the confidential nature of the CPO rules, and the discouraged use of 
CPO tickets by full-fare business travelers, the airlines 2120, 2130 can sell such excess 
capacity at a discount, without undennining its ejcisting published fare sinjcture. Thus, 
in a ptefeired embodiment, the RMS 2500 will periodically execute the CPO rule 
S generation process 3900. discussed below in conjunction with Figure 39. to generate 
CPO rules that encaurage the sale of tickets to CPO customers. 

DATABASES 

Figure 26 illustrates an exemplary customer database 2600 that 
preferably stores information on each customer of the CPO management system 2100, 
10 including biographical information and billing information, such as a credit card 
number. The customer database 2600 maintains a plurality of records, such as records 
2605-26 IS, each associated with a different customer. For each customer name listed in 
field 2640, the customer database 2600 includes the customcrls address in fleld 2645 
and credit caid number in field 2655. In addition, the customer account database 2600 
15 preferably Includes an identification (ID) number in field 2660. The ID number stored 
in field 2660 may be utilized, for example, to index a historical database (not shown) of 
previous ticket purchases and CPOs associated with the customer. 

Figure 27 illustrates an exemplary airline database 2700 which 
preferably stores information on each airline which is registered with the CPO 
20 management system 2I0O to sell airline tickets to CPO eustomens. including address 
and contact information. The airline database 2700 maintains a plurality of records, 
such as records 2705-2715, each associated with a different airline. ■ For each airline 
name listed in field 2740, the airline database 2700 includes address and contact 
infbnnaUon in fields 2745 and 2750, respectively. The contact information may 
V comprise, for example, the name of an individual employee of the airline 2120 and a 
conesponding telephone number, web page URL, bulletin board address, pager number, 
telephone number, electronic tnail address, voice mail address or facsimile number. 

In addition, in an embodiment where the CPO rules of a given airline are 
stored in an encrypted format, the cryptographic key of the associated airline is 
30 preferably stored in field 2755 of the airiine database 2700. Finally, the airline database 
2700 preferably stores an indicaticn in field 2760 of the percentage of CPOs which have 
been offered to each airiine which have actually been accepted by the respective airiine. 
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In this manner, the CPO management system 2 1 OO can offer a panicular CPO to airlines 
in a sequence that is ranked in accordance with the CPO acceptance rate, as discussed 
further below in conjunction with Figure 36b. In alternate embodiments, the airline 
database 2700 can incorporate fields to facilitate the processing of CPOs in accordance 
5 with sequences based on (i) the amount of inventory made available by each airline for 
sale to CPO customers, (ii) priorities negotiated by each airline, such as an airline 
priority over certain routes, or (iii) the highest commission raes paid by the airlines to 
the CPO management system 2100. 

Figure 28 illustrates an exemplary flight schedule database 2800 that 
10 preferably stores specific flight information for each O & D Pair, as well as connection 
information. The flight schedule database 2800 maintains a plurality of records, such as 
records 2805-2815, each associated with a different flight. For each O & D Pair listed 
in fields 2840 and 2845, the flight schedule database 2800 includes the date of each 
flight in field 2850, as well as the times of departure and anival of the re.spective flight 
IS in fields 2855 and 2860. The airline and flight number associated with each flight are 
preferably indicated in fields 2865 and 2870, lespectively, atid any required connections 
are indicated in field 2875. 

Figures 29a and 29b illustrate an exemplary CPO databa.se 2900 which 
preferably contains a record of each CPO being processed by the CPO management 
20 system 2100, including the terms of the CPO and the associated status. The CPO 
database 2900 maintains a plurality of reconjs. such as records 2905 and 2910, each 
associated with a different CPO being proeessed by the system 2100. For each CPO 
identified by CPO number in field 2920, the CPO database 2900 includes the date the 
CPO was received in field 2925, and an identification {E>) number for the travel agent, 
2S if any. associated with the CPO in field 2930. It is noted that the travel agent ID 
number stored in field 2930 may be utilized, for example, to index a historical database 
(not shown) of previous ticket purchases and CPOs associated with the travel agent. 

In addition, the CPO database 2900 identifies the customer by name in 
field 2935, and by identification number in field 2940 and identifies any companion 
30 passengers in field 2945. The ID number stored in field 2945 is preferably utilized to 
cioss-refeience the corresponding information stored for the customer in the customer 
database 2600. 
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The parameters of the customer's itinerary and other pertinent restrictions 
arc stored in fields 2950 through 2995 of the CPO database 2900. Specifically, the 
origin and destination cities are identified in fields 2950 and 29SS, respectively, and any 
connection restrictions specified by the customer 21 10 are recorded in field 2960. The 
5 dates of the customer^ departure and return are stored in fields 2955 and 2970, 
respectively. In an alternate embodiment (not shown), the CPO database 2900 could 
also permit the customer 2110 to specify particular limc-of-day (range) restrictions for 
the departure and return flights. 

The CPO database 2900 preferably stores an indication of the total 
10 number of passengers traveling together in field 297S, and sets forth the price the 
customer is willing to pay per ticket in field 2980. Any other miscellaneous restrictions 
specified by the customer will be recorded in field 2985, .such as preferred airline(s), 
flights, or seat assignments. Field 2990 records the current status of - the respective 
CPO, such as pending, accepted, rejected or expired. Finally, if the CPO ultimately 
IS results in a ticket being booked for the customer, the passenger name record number 
(PNR) associated with the ticket is stored in field 2995. Generally, u PNR is a record 
stored by the CSS 2400 containing information for each ticketed passenger, including: 
record number, passenger name(s), address for ticketing, billing information, such as 
credit card number, caiTiei<s) and flight numbetts) for all segments, seat assignments, 
20 inventory class, aircraft type, airline-issued authorization code for discounted fare, 
selling price, and additional comments. 

As discussed further below, rather than reject a CPO, one or more 
airlines may issue a binding counteroffer to the CPO, n^ich the customer 21 10 may 
accept or reject. If a counteroffer is issued to a customer 21 10, then a record of the 
25 cotmteroffer with any associated restrictions, is preferably created in the CPO duabase 
2900. For example, if an airiine 2120 issues a counteroffer to the CPO number 234S6 
stored in record 2905 of the CPO database 2900, then the status of die initial CPO is 
changed to "counter", and a further record (not shown) corresponding To the 
counteroffer may be stored in the CPO database 2900 under a modified CPO number 
30 indicating the counteroffer, such as CPO number 234S6-CO 1 . 

Figure 30a illustrates an exemplary secured airline rules database 3000 
which preferably maintains the CPO rules for one or more airlines associated with a 
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particular secured airline server 2300. As previously indicated, the secured airline rules 
database 3000 may be stored in an encrypted format to maintain the integrity and 
confidentiality of tlie highly sensitive information included in the CPO rules. The 
secured airline rules database 3000 maintains a plurality of records, such as records 
S 3002 and 3004, each associated with a different CPO rule. For each CPO rule identified 
by role number in field 3010, the secured airline rules database 3000 includes the 
associated restrictions defined by the respective airline in fields 3012 through 3044. 

According to a feature of the invention, the CE*0 rules that are processed 
by the CPO management system 2300 may be of varying complexity. The particular 
10 restrictions set forth in the illustrative secured airline rules database 3000 are 
representative of the principles of the invention only. An airline can incorporate a " 
subset of such restrictions and/or incorporate additional restrictions, as would be 
apparent to a person of ordinary skill. For example, the CPO rules of an airline 2120 
may also incorporate restrictions on the minimum number of ni^ts associated with the 
15 itinerary, or require the customer 21 10 to have a Saturday night .stay. 

For illustrative purposes, the secured airline rules databa.se 3000 shown 
in Figure 30a, allows an airline to create CPO rules by specifying some or all of the 
following restrictions in fields 3012 through 3044: origin and destination cities, 
connection restrictions, flight numbers included or excluded, dates and times of 
20 departure, departure days of the week, dates and times of reium. return days of the 
week, number of passengers traveling, length of haul, average yield per seal, minimum 
price per ticket, inventory restrictions or seat availability, and advance purchase 
requirements. 

For example, record 3002. shown in Figure 30a. is associated with a 
25 CPO rule for a given airline which specifies that the airline will accept any CPO for 
travel from Newark, New Jersey (EWR) to Orlando, Florida (MCO) during the month 
of October. 1997. provided that (i) the customer travels on any flight departing on a 
Tuesday through Thursday, (ii) the tickets are booked wiiUn 21 days of dqiarturc. (iii) 
the price is at least $165 per ticket, (iv) K inventory is available on all flight segments of 
30 the customer's itinerary and (v) at least two (2) passengers are travelling together. 

Similaily, record 3004, shown in Figure 30a, is associated with a CPO 
rule for a given aiiline which specifies that the airline will accept any CPO having a 
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price of at least $150. for two or more people traveling together between New York. NY 
(JFKl and Chicago, IL (ORD) during April or May, 1997 where Q or K inventory is 
available on any flight between 1 1 a.m. and 2 p.m., where the flight departs on a 
Tuesday and returns on a Monday through Thursday, and is booked between 7 and 21 
5 days prior to travel and can be routed through the airline^ Cleveland, OH or Pittsburgh. 
PA hubs. 

In an alternate or supplemental embodiment, the secured airline rules 
database 3000 can be implemented using a pair of inventory and pricing databases 3050. 
3075. illustrated in Figures 30b and 30c, respectively. In this embodiment, the CPO 

10 lules stored in the inventory database 3050 contain actual inventory on each flight that 
the airline has released for sale to CPO customers. The inventory databa.sc 30S0 
maintains a plurality of records, such as records 3052-3055, each associated with u 
different CPO rule and flight. For each CPO rule identified by rule number in field 
3060. the inventory database 3050 includes an indication of the airline, flight number 

IS and dates in fields 3062 through 3066. respectively. In addition, the number of .<waus 
that may be sold by the CPO management system 2100 on each flight is indicated in 
field 3068. In a preferred embodiment, as inventory is sold by the CPO management 
system 2100, the available inventory recorded in the inventory database 3050 will be 
decremented. 

20 The pricing database 3075, shown in Figuie 30c maintains a plurality of 

records, such as records 3080-3084, each associated with a different O & D Pair. For 
each O & D Pair identified in fields 3090 and 3092. respeaively, the pricing database 
307S. includes an indication of the airline, dates and minimum price in fields 3088. 3093 
and 3096, respectively. 

25 Thus, in such an alternate or supplemental embodiment, prior to 

accessing the inventory database 3050, the CPO management system 2100 will 
preferably query the CRS 240O to identify possible flights which satisfy the customer^ 
itinerary resttictions. Thereafter, the CPO management system 2100 will access the 
inventoiy database 3050 to determine if the airline has leleased any inventory on such 

3C identified flights to the CPO management system 2100 for sale to CPO customers. In 
one embodiment, the list of identified flights from the CRS 2400 can be sequenced to 
optimize customer prefienences. and the inventory database 3050 can be searched in the 
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order of the sequenced list of flights, until available inventoiy is identified. Finally, if 
any available inventory satisfying the 'customer% itinerary is identified, then the CPO 
management system 2100 will access the pricing database 3075 shown in Figure 30c, to 
determine if the price specified by the customer exceeds the minimum price defined by 

5 the airline, as set forth in field 3096 of the pricing database 3075, 

Rgure 31 illustrates an exemplary counteroffer rules database 3100 
which preferably stores a set of tolerances which may be utilized by the CPO 
management system 2100 to generate a counteroffer to a CPO if the CPO is within 
predefined tolerances of one or more restrictions associated with a given CPO rule. 

10 The counteroffer rules database 3100 maintains a plurality of record.";, such, as records 
3 105 and 3 1 10, each associated with a different CPO rule. For each CPO oilc identified 
by lulc number in field 3120, the counteroffer rales database 3100 includes acceptable 
tolerances on the dales and times of depanurc and return in fields 312S through 3140. 
In addition, the counteroffer rales database 3100 includes tolerances on the number of 

15 passengers traveling, length of haul and yield in fields 3 145 through 3155, respectively. 
Finally, the counteroffer rales database 3100 records any permissible tolerances on the 
minimum price and advance purchase requirements in fields 3160 and 316S, 
respectively. 

As shown in Figure 31, the counteroffer rule.? database 3100 includes 
20 counteroffer rale number 45687 in record 3105, corresponding to CPO rale number 
45687 from Figure 30a. As illustrated in Figure 3 1 , the CPO management system 2100 
is authorized to generate a counteroffer on behalf of an airline 2120 associated with 
CPO rale number 4S687, if a given CPO fails to meet one or more of the restrictions of 
CPO rule number 45687, but the restrictions which are not met are within the 
25 predefined tolerances set forth in the counteroffer rules database 3 100. For example, if 
a given CPO includes a customer-defined price of SI40.00, bui all other airline-defined 
restrictions of CPO rale number 45687 are met, a counterofTer should be generated 
containing a price of S ISO.OO since the price variation is within ten pert»nt (10%) of the 
minimum price associated with CPO rule number 45687, as authorized by counteroffer 
30 rale number 45687. 

Figure 32 illustrates an exemplary secured airiine audit database 3200 
which preferably maintains an audit traU for each CPO which is processed by the CPO 
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tnanagemeni sysiem 2100. The secured airline audit database 3200 maintains a 
plurality of recoids, such as records 3205-3215, each associated with a different CPO 
that has been processed by the CPO management system 2100. For each CPO 
identified by CPO number in field 3220, the secured airtine audit database 3200 
S includes the response of the respective airline to the CPO in field 3225, and the date and 
time of the CPO In fields 3230 and 3235. respectively. In addition, if a ticket is booked 
for the customer 2110 on any airline, then the secured airline audit database 3200 
preferably stores the passenger name record (PNR) number associated with the ticket in 
field 3240 and an indication of whether or not the ticket was booked on the respective 
10 airline in field 3245. In a preferred embodimeni. the entry in field 3245 indicates 
whether the ticket was booked (a) on the respective airline associated with the database, 
(b) with another airline or (c) If no ticket was i.ssued at all. In this manner, the CPO 
management system 2100 can establish that a ticket was actually booked for each CPO 
which was accepted by at lca.M one airline. 
IS Figure 33 illustrates an exemplary pricing and restrictions database 3300 

which maintains pricing infonnation and related restrictions for each flight offered by 
the airlines 2120, 2130, as established and updated by the RMS 2S0O. The pricing and 
restrictions database 3300 includes a plurality of records, such as record-i 3305-33 IS, 
each associated with a different flight. For each flight identified by flight number in 
20 field 3325, the pricing and restriciion.s database 3300 includes the date of the flight in 
field 3330 and the respective price and restriciions associated with each inventory class 
in fields 333S through 33S0. 

Figure 34 illustrates an exemplary seat allocation database 3400 which 
mainuins available invemory information for each fare class on a given flight offered 
2S bytheairltnes2l20, 2130, as allocated and updated by the RMS 2500. In addition, as 
inventory is sold by an airline, the aitlinel^ ARS 21S0 will preferably decrement the 
available inventory recorded in the seat allocation database 3400. The seat allocation 
database 3400 includes a plurality of'records. such as records 3405-3420, each 
associated with a different flight. For each flight identified by flight number in field 
30 3425, the seat allocation database 3400 includes the departure date of the flight in field 
3430 and the respective inventory available in each invemory class in fields 343S 
through 3440. In addition, the seat allocation database 3400 preferably includes an 
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indicaiion of the total number of seas booked on the flight in field 3445 and total 
capacity available on the flight in field 3450. 

Figure 35 illustrates an exemplary forecast and demand analysis database 
3500. which records each selling price for each fare class for a given flight, and the 
5. forecasted demand at each selling price as established by the RMS 2500. As previously 
indicated, when a flight is first added to the flight schedule of an airline 2120, a record 
of the initial price for each fare class and the forecasted demand is preferably created in 
the forecast and demand analysis database 3500. In addition, new records are 
preferably created for each new selling price diat is established for each fare cla.ss by the 
10 RMS 2500. as pan of the dynamic inventory reallocation process. 

The forecast and demand analysfs database 3500 includes a plurality of 
records, such as records 3505-3525, each associated with a diffcient selling price for a 
given fare class on a given flight. For each flight number identified in field 3530. the 
forecast and demand analysis database 3500 includes the departure date, and origin and 
15 destination cities in fields 3535 through 3545, respectively, and the correiipondinB 
offered prices and fare classes in fields 3550 and 3555. respecuvely. Finally, the 
forecast and demand analysis database 3500 preferably records the actual quantity of 
tickets $old by the airline at each offered price for each fare class in field 3560 and the 
corresponding forecasted quantity in field 3565. The actual quantity of tickets sold may 
ai be recorded in field 3560 in real-time as tickets are actually sold or by means of baich 
processing on a periodic basis. 

PROCESSES 

At discussed above, the CPO management central server 2200 preferably 
executes a CPO managemcni process 3600. shown in Figures 36a through 36c. to 

25 receive each CPO from a customer 21 10 and to compare the CPO against the rules of 
each airilne in order to determine whether to accept, reject or counter the CPO on behalf 
of an airline. As illustrated in Figure 36a. the CPO management process 3600 begins 
the ptf)cesses embodying the principles of the present invention during step 3604. when 
a customer or travel agent accesses the CPO management system 2100. 

30 Thereafter, during step 3608, the CPO management central server 2200 

will receive the customer information, itinerary, price and other restrictions from the 
customer 2110 which are required to populate the customer database 2600. if required 
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for a new customer, and the CPO database 2900. A record of the CPO is preferably 
created in the CPO database 2900 with the received infonnaticm during step 3612, and 
with the status field set to "pending." 

Appropriate legal language is preferably displayed or read to the 

S customer 21 10 during step 3616, and the CPO management system 2100 will wait for 
an acknowledgnwnt from the customer 2110 to form a binding conditional purchase 
offer (CPO). The price is extracted from field 2980 of the CPO database 2900 and the 
appropriate customer information, including credit card number, is extracted from the 
customer database 2600 during step 3620. Thereafter, the merchant ID associated with 

10 the CPO management system 2100. together with an appropriate billing descriptor, (he 
total purchase amount (preferably equal to the price specified by the customer 21 10) 
and the credit card information, arc transmitted to the aedit card issuer during step 3624 
for pre-authorization. 

A test is then preferably performed during step 3628 to determine if an 

IS authorization code ha.s been received from the credit card issuer. If It is determined 
during step 3628 that the credit card issuer has not authorized the purchaw amount, then 
another credit card is preferably requested from the customer 21 10 during step 3632 and 
program control returns to step 3624 to continue processing in the manner described 
above. 

20 If, however, it is dctennined during step 3628 that the credit card issuer 

has authorized the purchase amount, then the CPO is accepted for processing during 
step 3636 and program control continues to step 3640 (Figure 36b). The CPO 
management process 3600 preferably executes the evaluation process 3700, discussed 
below in conjunction with Fignte 37, for each airline during step 3640. The CPO record 

2S created during step 3612 is passed to the evaluation process 3700 for comparison 
against the CPO rules of one airline, such as the airline 2120, to generate a response for 
the airline to the given CPO. As previously indicated, the airiine's response to a CPO 
may be to accept, reject or counter the CPO. As discussed fiitther below, the evaluation 
process 3700 will return the airline's resptmse to the CPO, as well as a flight number if 

30 the CPO is accepted or countered by the airiine. 

In an alternate embodiment, the evaluation process 3700 can be 
perfomied for each airline in a predefined sequence until one airline accepts the CPO. 
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For example, (he evaluation process 3700 can be performed in sequence based upon (i) 
the amount of inventory made available by each airline for sale to CPO customers, (ii) 
the CPO acceptance rate of each airline, as recorded in the airline database 3700, (ili) 
priorities negotiated by each airline, such as an airline priority over cenain loutes. or 

5 (iv) the highest commission rates paid by the airlines to the CPO management system 
2100- h this manner, the sequence can be determined by factors that incent 
participation by the airlines, and/or by factors that optimize revenue to the CPO 
management system 2100. It is noted (hat in the preferred embodiment, the customer 
2110 will pay the price defined by the customer if the CPO is accepted by an airiine, 

10 regardless of the minimum price the airline would be willing to accept or whatever 
sequencing criteria is utilized by the CPO management system 21O0 to process the 
CPO. 

As shown in Figure 36b. a test is preferably performed during step 3644 
to determine if the CPO was accepted by at lea.<u one airiine. If it is determined during 
15 step 3644 that the CPO was accepted by at least one airline then a further lest is 
preferably performed during step 3648 to determine if the CPO was accepted by more 
dian one airiine. If it is deleimined during step 3648 that the CPO was not accepted by 
more than one airiine then program control proceeds directly to step 3672 (Figure 36c) 
to book the ticket. 

20 If. however, it is determined during step 3648 that the CPO was accepted 

by more than one airiine. then a tie breaker algorithm is preferably executed during .step 
36S2 10 determine which airiine acceptance to utilize. For example, the tie breaker 
algorithm can select an airiine offering an itinerary which maximizes the convenience to 
the customer 2110, maximizes the profit to the CPO management system 2100 or 

25 optimizes the inventory available for sale by the CPO management system 2100. U is 
noted that in the ahemate embodiment, where the evaluation process 3700 is performed 
for each airtines in a predefined sequence until one airiine accepts the CPO. a lie 
breaker algorithni will not be required. In a further alternate embodiment, the customer 
21 10 may select for himself which airline acceptance to utilize. Thereafter, program 

30 control pioceeds to step 3672 (Figure 36c) to book the tidceL 

in order to book die ticket, the information required to create a passenger 
name lecord (PNR) is extracted fnHn the customer database 2600, the CPO database 
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2900 and the inventory and flight information received from the evaluation process 
3700 or CRS 2400. As previously indicated, a PNR generally includes the following 
parameters; record number, passenger name(s), address for ticketing, billing 
infonnation, such as cretUt card number, flight number(s) for all segmenu, carrjer(s), 
seat assignments, inventoiy class, aircraft type, airline-issued authorization code for 
discounted fare, selling price, and additional comments. 

Thereafter, during step 3674. the PNR is transmitted to the airline 
reservation system 2150 of the airline upon which the ticket will be booked or the CRS 
2400 to establish a reservation. The CPO management process 3600 will then transmit 
the merchant ID associated with the CPO management system 2100, together with an 
appropriate billing descriptor, the total purchase amount (preferably equal to the price 
specified by the customer 21 10) and the credit caid information, to the credit card issuer 
during step 3678 for payment. 

The record of the CPO in the CPO daubase 2900 is updated during step 
15 3682 with the assigned PNR number and the status ncld is changed to "accepted." 
Finally, an audit process 3800, discussed below in conjunction with Figure 38. is 
executed by the CPO management process 3600 during step 3686 for each airline to 
maintain an audit nail for each CPO which is processed by the CPO management 
system 2100. As previously indicated, the audit process 3800 will create an entry in the 
20 secured airline audit database 3200 which can be utilized to establish thai a ticket was 
actually booked by the CPO management system 2100 for each CPO which was 
accepted by at least one airline. 

If, however, it was determined during step 3644 (Figure 36b) that the 
CPO wa.s not accepted by at least one airline, then a further lest is performed during step 
25 3656 to determine if at least one airline provided a counteroffer to the CPO. If it is 
determined during step 3656 that at least one airline did provide a counteroffer lo the 
CPO, then the status of the initial CPO Is changed to "counter", and a record of the 
counteroffer is piefeiably created in the CPO database 2900 during step 3660, for 
example using the original CPO number with a "-CO" extension. Thereafter, the 
30 coumeToffer(s} are transmitted to the customer 21 10 during step 3664. In an alternate 
emboiUinent, if the CPO is within ptedefined tolerances, rather than receiving one or 
more counteioffeis, the cqstomer 21 10 can be instructed to resubmit the CPO at a later 
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litne, or the CPO management system 2100 can periodically reexecute the CPO until the 
CPO is accepted or until the CPO expires. It is noted that in view of the dynamic nature 
of the CPO rules, a CPO thai is initially rejected may be subsequently accepted by one 
or more airlines. 

S A test is than preferably performed during step 3668 lo determine if the 

customer 2110 accepted one of the counteroffer(s). If it is deteraiined during step 3668 
that the customer 21 10 did accept a counteroffer, then program control proceeds to step 
3672 (Figure 36c) to book the ticket, in the manner described above. If. however, it is 
determined during step 3668 that the customer 2 1 10 did not accept a counteroffer, then 
10 program control proceeds to step 3696 (Figure 36c). where the CPO management 
process 3600 will transmit the customer's rejection of the counteroffer to the airline(s) 
making the counteroffer. Thereafter, during step 3698, the CPO management process 
3600 will update the status of the counteroffer associated with the CPO in the CPO 
databsuic 2900 to "rejected." Program control proceeds to step 3686 in ihe manner 
IS described above and then terminates during step 3699. 

If, however, it was determined during step 3656 (Figure 36b) that no 
airlines provided a counteroffer to the CPO, then program control proceeds to step 3690 
(Rgure 36c), where the CPO nuinagement process 3600 will transmit the rejection of 
the CPO to the customer 21 10. Theieafter, the status of the CPO in the CPO database ' 
20 2900 is updated to "rejected" during step 3694. Program control proceeds to step 3686 
in the manner described above and then terminates during step 3699. 

As discussed above, the CPO management process 3600 executes an 
evaluation process 3700, during step 3640. An exemplary evaluation process 370O is 
shown in Figures 37a and 37b. In one embodiment, the evaluation process 3700 is 
25 preferably customized for each airline, so that each evaluation process 3700 receives IhC 
CPO record from the CPO management process 3600 in a standard format for 
comparison against the rules of the associated airline, such as the airline 2120. and 
returns a standard response of Ihe airiine to the CPO, such as accepf, leject or counter. 
In addition, if the response of the airline is to accept or counter the CPO, the evaluation 
30 process 3700 preferably also returns the selected fli^t number. 

As shown in Figure 37a, the evaluation process 3700 initially extracts the 
O & D Pair from the CPO record during step 3705 and thereaftn identifies all CPO 
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rules in the secured airline rules database 3000 which are pertinent to the extracted O & 
D Pair during step 3710. The customer defined restrictions from fields 2960 through 
299S of the CPO tecord are then compared to the conesponding airline defined 
restrictions from rietds 3016 through 3044 of the secured airline niles database 3000 

5 duringstep3715,foreachCPOnileidentifitdduringtheprieviousstep. 

Thereafter, a test is performed during step 3720 lo determine if the CPO 
satisOes at least one airline rule. For example, CPO number 234S2, stored In record 
2910 of the CPO database 2900 (Figures 29a and 29b), defines an O & D Pair of New 
York (JFK) to Chicago (ORD). Thus, the evaluation process 3700 will access the 

10 secured airline rules database 3000 and identify all CPO rules for this O & D Pair. In 
the illustrative secured airline rules database 3000 shown in Figure 30a. CPO rule 
number 234S2 is identified as the only rule pertinent to this 0 & D Pair. Thereafter, 
each of the customer defined restrictions from fields 2960 through 299S of the CPO 
number 23452 are compared to the corresponding airline defined restrictions from fields 

15 30 J6 through 3044 of CPO rule number 23452. Since the customer is willing to make 
one stop (field 2960), the airline requirement of routing through Cleveland or Pitt.sburgh 
(field 3016) can be satisfied. In addition, the customer^ dates of departure and return 
requirements (fields 296S and 2970) satisfy the airline'^ dates, times and day of week 
requirements for both the departure and letum legs of the trip (fields 3020 through 

20 3032). In addition, the number of passengers traveling satisfies the airline requirement 
set forth in field 3034 and the customer's price (fieW 2980) exceeds the airline's defined 
minimum price (field 3040). Thus, CPO number 234S2 will be accepted by the airline 
associated with CPO rule number 45687, piov'ided that Q or K inventory is available 
(field 3042) and the CPO is being processed between 7 and 21 days prior to flight (field 

25 3044). 

' in one embodiment, the CPO nnanagement system 2100 allows the 
airlines 2120. 2130 to specify CPO rules in a format that accepts a given CPO, 
conditioned upon the CPO managetnent system 2100 finding inventory available that 
meets the requirements of the airline, as set forth in the CPO rule, and the requirements 
30 of the customer 21 10, as set forth in die CPO itself. For example, CPO rule number 
23452. shown in Figure 30a, is conilitioned upon Q or K inventory being available. 



80 



PCTAJS97/1S492 



Thus, if it is determined during step 3720 that the CPO satisfies at least 
one airline rule, then a further test is preferably performed during step 3725 to 
determine if any of the satisfied rules are conditioned on inventory being available. 

If it is delctmined during step 372S that none of the satisfied fules arc 
5 conditioned on inventory being available, then program control proceeds directly to step 
3735, discussed below. If, however, it is determined during step 3725 that one or more 
satisfied rules ate conditioned on inventory being available, then the CRS or ARS is 
accessed during step 3730 to identify flights, if any, with seats available and meeting the 
appropriate restrictions of both the satisfied CPO rule and the CPO. 
10 Thereafter, a test is performed during step 3735 to determine if more 

than one flight satisfying the CPO has been identified. If it is determined during step 
3735 that only one satisfactory flight has been Identified, then program control proceed.^ 
directly to step 3745 (Figure 37b), discussed below. 

If, however, it is determined during step 3735 that more than one 
IS satisfactory flight has been identified, then one flight is selected during step 3740 
(Figure 37b) whidi most closely matches the customer preferences set forth in the CPO 
or maximizes the convenience for the customer. Alternatively, each airiinc 2120 can 
define its own criteria for the CPO management system 2100 to utilize to select a single 
flight. Thereafter, the response will be set to "accept" during step 374S. and program 
20 control will return to the CPO management process 3600 during step 3770 with the 
defined response and selected flight number. 

If, however, it was determined during step 3720 (Figure 37a) that the 
CPO does Dot satisfy at least one airline rule, then program control proceeds to step 
3750 (Figure 37b), where a fuither test is petfonned to determine if the CPO is within 
25 tolerances specified by the airline for generating a counteroffer. As previously 
indicated, the counteroffer rules database 3100 is preferably stored by each secured 
airline server 230O to maintain a set of loleiances which may be utilized by the CPO 
management system 2100 to generate a counteroffer to a CPO on behalf of an airline, if 
the CPO is within predefined tolerances of one or more leslrictions associated with a 
30 given CPO rule. 

Thus, if it is determined during step 37S0 that the CPO is within 
tolerances specified by the uriine for generating a counteroffer, then a counteroffer is 
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generated during step 3760 with the appropriate inodified terms, as retrieved from the 
counteroffer rules database 3100. Thereafter, the response will be sec to "counter" 
daring step 376S, and program control will return to the CPO management process 3600 
during step 3770 with the defined response and selected flight number. 
5 If, however, it is determined during step 3750 that Ihc CPO is not within 

tolerances specified by the airline for generating a counteroffer, then the response will 
be set to "rejected" during step 3755, and program control will return to the CPO 
management process 3600 during step 3770 with the defined response and the selected 
flight number equal to null. 
10 As previously indicated, the CPO management process 3600 preferably 

executes an audit process 3800 during step 3686 for each airline to mainiain an audit 
trail for each CPO that is processed by the CPO management system 2100. An 
exemplary audit process 3800 is shown in Figure 38. The audit process 3800 will 
pieferably create an entry in the secured airlme audit database 3200 which can be 
15 utilized by the CPO management system 2100 to establish that a iickei was actually 
booked by the CPO management system 2100 for each CPO which was accepted by at 
least one airiine. In this manner, the airlines 2120 can be assured that the risk of a 
customer 2110, another airline 2130 or a third party utilizing the CPO management 
system 2 100 to obtain the underiying price nexibility of the airline 2 1 20 is minimized. 
20 As shown in Figure 38. the audit process 3800 will initially decrement 

the inventory in the secured airiine rules database, if necessary, during step 3810. For 
example, inventory should be decremented only if the ticket was ultimately booked by 
the associated airline, and the CPO rule which was utilized to accept the CPO actually 
included inventory released by the airiine for sale to CPO customers, as opposed to a 
25 CPO lule which was conditioned upon invemoiy being available. 

Thereafter, the audit process 3800 preferably creates a record of the CPO 
in the secured airiine audit database 3200, during step 3813, including the CPO number, 
the PNR associated with the ticket issued by the CPO management system 2100, if any, 
to the customer 21 10. and an indication of whether the ticket, if any, was booked on the 
30 coiresponding airline. Program control will then return to the CPO management 
process 3600 during st^ 382a 



82 



WO98/10M1 



PCT/US97/I5492 



An illustrative CPO mics generation process 3900, shown in Figure 39, 
is pteferably executed by the RMS 2500 initially when a flight is first added to the flight 
schedule, and then periodically to reallocate and piice available inventory in response to 
demand and external events. Thus, a test is initially performed during step 390S to 

5 determine if the current inventory allocation by the RMS 2500 is the initial allocation 
for the flight being allocated. If it is determined during step 3905 that the current 
inventory allocation is the initial allocation for the flight being allocated, then a further 
test is performed during step 3910 to determine if the flight is predicted, using 
conventional methods, to likely depart with empty seats. 

10 If it is determined during step 3910 that the flight is not likely to depart 

with empty seats, then program control will terminate during step 398S. If, however, it 
is detennined during step 3910 that the flight is likely to depan with empty seats, then 
the CPO rule generation process 3900 will preferably allocate the empty seats to a 
special fate class for CPO customers during step 39 IS. Thereafter, an appropriate 

IS minimum fore and other restrictions for such tickets will be established during step 
3920. 

The pricing and restrictions database 3300, scat allocation database 3400, 
and forecast and demand analysis database 3 SOD for the flight will be updated during 
step 392S with the newly established fare class, the allocated inventory and the initial 
20 price. Thereafter, the CPO rules generation process 3900 will preferably generate a 
CPO rule containing the allocated inventory, established minimum price and other 
restrictions during step 3930 and then transmit the generated CPO rule to the associated 
secured airline server 2300 during step 3933. Program control will then terminate 
during siqi 3985. 

2S If. however, it was determined during step 3905 that the curreni 

inventory allocation is not the initial allocation for the flight being allocated, then 
program control proceeds to step 39S0 to reallocate a previous allocation for one or 
more fare classes of a given flight in order to minimize the imanticipated excess 
inventory delta 2580. Thus, a test is performed during step 3950 to determine if the 

30 forecasted demand exceeds the actual demand by more than a predefined tolerance for 
any fare class. In one embodiment, the RMS can make tUs determination utilizing the 
summary information recorded in fields 3560 and 3S6S of the forecast and demand 
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analysis database 3500. In addition, the RMS 2500 can generate the predefined 
tolerance utilized in step 3950 by analyzing historical demand information stored in the 
forecast and demand analysis database 350O for prior periods. 

If it is determined during step 39S0 that the forecasted demand does not 
S exceed the actual demand by more than a predefined tolerance for any fare class, then 
there is no need to reallocate the existing allocation md program control will terminate 
during step 3985. It is noted that if actual demand exceeds forecasted demand, the RMS 
2S00 can temove inventory that was previously allocated for sale to CPO customers. 

If, however, it is determined during Step 39S0 that the foiieca.<ited demand 
10 does exceed the actual demand by more than a predefined tolerance for any fare class, 
then the RMS 2500 will preferably allocate the excess capacity, or a portion thereof, for 
sale to CPO customers during step 3955. Thereafter, an appropriate minimum fare and 
other restrictions for such tickets will be established during step 3960. 

The pricing and restrictions database 3300, seat allocation database 3400. 
IS and forecast and demand analysis database 3S00 for the flight will be updated during 
step 3965 with the reallocated inventory and the established price. Thereafter, the CPO 
mies generation process 3900 will generate a CPO rule Containing the allocated 
inventory, established minimum price and other restrictions during step 3970 and then 
transmit the generated CPO mie to Uie associaed secured airline server 2300 during 
20 step 3980. Program control will then terminate during step 3985. 

CRUISE IMPLEMENTATION 
Although the CPO managemoit system 2100 has been primarily 
illustrated herein as a system for selling airline tickets, the CPO management system 
21X10 could be utilized to sell cmise tickets as well, as would be apparent to a person of 
25 ordinary skill. In such an embodiment, each secured airiinc server 2300 would be 
associated with one or more cruise operatois, as opposed to airlines, and each secured 
server 2300 stores, among other things, the CPO rales defined by any associated cniise 
operators, in a similar manner to the secured server 2300 described above in an airline 
implementation. 

30 In addition, the revenue management system 2500 and the airline 

reservation system 2150 would be embodied as the revenue management system and 
reservation system, respectively, of each cmise operator. The cruise revenue 
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management system establishes pricing and inventory information and generates CPO 
rules in a similar manner to the revenue management system described above in an 
airline implementation. Similarly, the cmise reservation system performs itinerary 
queries and makes reservations with the respective cniise operator in a similar manner 

S to the reservation system described above in an airline implementation. 

Thus, the CPO management system 2100 receives CPOs from potential 
cruise travelers and evaluates the CPOs against a set of CPO rules provided by each of a 
plurality of cniise operators. An illustrative CPO database 4000 for a cruise 
implementation is illustrated in Figures 40a and 40b. The CPO database 4000 

10 preferably stores a record of each CPO being processed by the CPO management 
system 2100, including the terms of the CPO and the associated status. The CPO 
databa.se 4000 maintains a plurality of records, such as records 4005 and 40 10, each 
associated with a different CPO being processed by the system 2100. For each CPO 
identined by CPO number in field 4020, the CPO databa.sc 4000 includes the date the 

IS CPO was received in field 4025, and an identification (ID) number for the travel agent, 
if any, associated with the CPO in field 4O30. it is noted that the travel agent ID 
number stored in field 4030 may be utilized, for example, to index a historical database 
(not shown) of previous ticket purchases and CPOs associated with the uavel agent. 

In addition, the CPO database 4000 identifies the customer by name in 

20 field 4035. and by identification number in field 4040. Any companion passengers arc 
identified in field 404S. The ID number stored in field 4040 is preferably utilized to 
cross-reference the corresponding information stored for the customer in the customer 
database 2600. 

The parameieis of the customerls itinerary and other peninent restrictions 
2J are stored in fields 4050 through 4085 of the CPO database 4000. Specifically, the 
origin and destination ports are identified in fields 4050 and 4055, respectively, and any 
. port restrictions specified by the customer 2110 are recorded in field 4060. The 
departure and return dates are stored in fields 4065 and 4070, respectively. 

The CPO database 4000 preferably stores an indication of the total 
30 number of passengers traveling together in field 4075, and sets forth the price the 
customer is willing to pay per ticket in field 408O. Any other miscellaneous restrictions 
specified by the customer will be recorded in field 4085, such as preferred cruise 
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opcratoi(s), berths, cabin assignments or meal times. Field 4090 records the current 
status of the respective CPO, such as pending, accepted, rejected or expired. 

An iilusnative secured rules database 4 1 00 for a cruise impletncntation is 
shown in Figure 41 for maintaining the CPO rules for one or more cruise operators 
5 associated with the respective secured server 2300. The secured rules database 4100 
may be stored in an encrypted formal to maintain the integrity and confidentiality of Ihe 
highly sensitive information included in the CPO rules. The secured rules database 
4100 maintains a plurality of records, such as recotds 4102 and 4104, each associated 
with a different CPO rule. For each CPO rule ideniifled by rule number in field 4110, 
10 .the secured rules database 4100 includes the associated restrictions dcflned by the 
respective cniise operator in fields 4112 through 4144. 

According to a feature of the invention, the CPO rules that are processed 
by the CPO management system 2100 may be of varying complexity. The particular 
restrictions set forth in Ihe illustrative secured lules database 4100 are representative of 
15 the principles of the invention only. A cniisc operator, airline or other seller can 
incorporate a subset of such restrictions and/or incorporate additional restrictions, as 
would be apparent to a person of ordinary skill. 

For illusnrative purposes, the secured rules database 4100 shown in 
Figure 41, allows a cruise operator to create CPO rules by specifying some or all of the 
20 following restrictions in fields 4112 through 4144: origin ports, cruise numbers 
(included or excluded), dates and times of departure, departure day of the week, dates 
and times of return, return day of the week, number of passengers (raveling, length of 
haul, average yield per cabin, minimum price per ticket, inventory restrictions or cabin 
availability, and advance purchase requirements. 
25 I^r example, record 4 1 02. shown in Figure 4 1 . is associated with a CPO 

rule for a given cruise operator which specifies that the cruise opeiator will accept any 
CPO for uavel from St. Thomas during the month of October, 1997. provided that (i) 
the customer travels on any cruise departing and returning on a Tuesday through 
Thursday, (ii) the tickets are booked within two (2) months of departure, (iii) the yield is 
30 at least $1 .20 per mile per cabin and the price is at least SS29 per person, (i v) is not for 
loxury class travel and (v) at least two (2) passengers are travelling together. 
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POST-SELL FOR MULTIPLE BINDS 
As discussed above, if a CPO is accepted by more than one airline or 
Cfuise operator, then a tie breaker algorithm is preferably executed by the CPO 
management process 3600 during stop 3652 to determine which airline acceptance to' 
5 utilize. For example, the lie breaker algorithm can select a seller offering an itinerary 
which maximizes the convenience to the customer 21 10. maximizes the profit to the 
CPO management system 2100, optimizes the inventory available for sale by the CPO 
management system 2100 or permits the customer 2110 to select for himself which 
airline or cruise operator acceptance to utilize. In an alternate implementation, if a CPO 
10 is accepted by more than one cruise operator, the CPO management system 2100 
execuie.s a post-sell mulli-bind process 4200, shown in Figure 42, to permit each 
accepting seller to directly market to the customer 21 10 and post-sell their product. 
Thus, the customer 21 10 still selects for himself which cruise operator acceptance to 
utilize. ba.sed on materials or incentives furnished by each seiler. The customer 21 10 is 
15 still bound by the CPO management system 2100, in accordance with the terms of the 
CPO. In other words, the customer 21 10 is obligated to purchase the goods or services 
specified by the CPO, but the buyer must decide which cruise operator to utilize, based 
on materials ptovided to the customer 21 10 directly by each accqjting cruise operator. 

For example, a customer 2110 may submit a CPO for a croisc during the 
20 month of March. 1998, anywhere in the Virgin Islands, in a grade A cabin with late 
dining, for $800.00. The CPO is provided to a plurality of ciuise operators. Three 
cruise operators accept the CPO. The CPO management system 2100 then binds the 
customer 21 10 on the credit card account identified with the offer, in accordance with 
the restrictions of the CPO. The CPO management system 2100 then provides a 
25 channel of communication between the customer 2110 and the accepting sellers, or 
provides the customer contact information to each accepting eiuise operator, who each 
aiiempi to market their product in an aimctive manner. The customer 21 10 then selects 
one of the three accepting sellers. Thus, each cruise operator knows that they have a 
one-in-three chance of selling a ciuise. at the price specified by the CPO. It is 
30 anticipated that cruise operators would aggressively market to such guaranteed 
puichasers, particularly in view of the high marginal profits asstxiated with each cruise 
traveler.. 
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It is noted that the channel of communication provided by the CPO 
inanagein«)t system 2100 between the customer 21 10 aad each accepting seller may be 
an interactive web-site or other electronic mechanism thai permits each accepting seller 
to present the customer 2110 with detailed information about the cruise they are 
S attempting to marliet. For example, the interactive web-site might include virtual 
representations of different aspects of the cruise package, such as the actual cruise ship 
and cabins, as well as the various ports that the cruise will visit and the available 
activities. In this manner, the buyer can explore the vinual cruise representation using 
Icnown technology. 

10 ' Figure 42 illustrates an illusirative post-sell multi-bind process 4200 

which may be implemented by the CPO management central server of Figure 22 to 
permit each accepting seller to directly market to the customer 21 10 in an atteinpt to 
post-sell their product. The post-sell muili-bind process 4200 is preferably executed by 
the CPO management process 3600 during step 36S2. in lieu of the tie breaker 
15 algorithm, lo determine which cruise operator acceptance to utilize. As illustrated in 
Figure 42, the post-sell multi-bird process 420O begins during step 4210. by instructing 
the accepting cruise operators or other sellers lo provide post-sell information for a 
designated customer 21 10. The CPO management system 2100 then preferably receives 
the post-sell infomnaiion from the accepting operators during step 4220 and transmits, 
20 or otherwise makes available, the received information to the customer 2110 during step 
4230. Finally, the post-sell multi-bind process 4200 receives the decision of the 
customer 2110 regarding which operator to utilize, befote program control returns to the 
CPO management process 3600 during step 42SO. 

In an alternate implementation, if a CPO is accepted by more than one 
15 cruise operator, then the CPO management system 2 tOO can bind each of the accepting 
sellers to the one CPO. The original buyer can be assigned one of the sellers in 
accordance with the tie breaker algorithm or the altemadve post-sell multi-bind process 
4200 disclosed heiein. In this manner, the CPO management system 2100 can then 
resell the excess inventory to other buyers at or above the price associated with the 
30 initially accepted CPO. 
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EXCLUDED SELLER CPO EVALUATION 
As previously indicated, a CPO submitted by a customer 21 10 can 
specify one or more preferred airline(s), cniise operators or other sellers, as applicable. 
Thus, the CPO management system 2100 will provide the CPO to each specified seller 
5 to determine if one or more of the sellers are willing to accept the CPO. In a 
supplemental embodiment, the CPO management system 2100 preferably executes an 
excluded seller CPO evaluation process 4400, discussed below in conjunction with 
Figures 44a and 44b. to provide the CPO to the excluded sellers who may make 
counteroffers to the customer 21 10 before one of the specified sellers accepts the CPO. 
10 The exchided sellers may make coumeroffers which ate more favorable than the 
original terms of the CPO specified by the customer 21 10, in an attempt to obtain the 
business. In this manner, the CPO management system 2100 can sell the rights to 
receive CPO information to excluded sellers or collect a larger percentage commission 
for any counteroffers which are accepted by a customer 21 10. 
15 For example, in the cmise industry, first time cruisers tend to develop a 

specific brand loyalty. Thus, when considering future cruises, such cu-stomers 2110 
may submit a CPO to a very limited number of cruise operators. The CPO management 
syiitem 2100 would submit the CPO to the specified cmise operators, in accordance with 
the terms of the CPO, and also submit the CPO to one or more excluded cniise 
20 operators. The CPO management .system 2100 preferably utilizes an excluded operator 
counteroffer database 4300, shown in Figure 43. to maintain any counteroffers nxcivcd 
from the excluded operators, befote thfe CPO is accepted by one of the customer- 
specified operators. 

An illustrative excluded operator counteroffer database 4300 for a cruise 
3S implementation is .shown in Figure 43. The excluded operator counteroffer database 
4300 maintains a plurality of records, such a.<; records 430S through 43 IS, each 
associated with a different counteroffer received from an excluded operator. For each 
counteroffer iduKifted by nuiiiber in field 4325, the excluded operator counteroffer 
database 4300 includes the corresponding CPO number, a customer identifier, the 
3D excluded operaior, the terms of the counteroffer and the associated status in fields 4330 
through 43S0. respectively. For example, if a customer's CPO initially specified that 
the offer be submitted to Holland AmeiicaLine or Seaborti Ciuisie Lines, the CPO 
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management system 2100 might first subtnii the offer to Carnival, Princess and Royal 
Caribbean Cniise Lines. As shown in Figure 43. each of the excluded operators submit 
counteioffets of $600, $600 and $575, respectively, If none of the operators originally 
specified by the customer's CPO have not yet accepted, then the customer 2110 is 
5 provided the option of accepting one of the counterofTers. If the customer 21 (0 accepts 
a counteroffer, then the customer 21 10 is bound to the terms of the counteroffer, and the 
original CPO is cancelled. 

Figures 44a and 44b describe an illustrative excluded seller CPO 
evaluation process 4400. This process 4400 may be implemented by the CPO 
10 management central server of Figure 22 to provide the CPO information to the sellers 
excluded by the terms of the original offer. Those excluded sellers can then attempt to 
obtain the business, before one of the sellers specified by the terms of the CPO accepts 
the CPO. As discussed below, the excluded seller CPO evaluation process 4400 is 
preferably executed in conjunction with the CPO management process 3600. As 
IS illustrated in Figure 44a, the excluded seller CPO evaluation process 4400 begins during 
step 4405, upon receipt of a CPO from a customer 21 10 and storage of the CPO in the 
CPO database 2900 or 4000. Thereafter, the CPO is evaluated during step 4410 to 
reuieve any operators specified by the customer 2110. The opeiator database is 
accessed during step 4415 to identify potential operators to which the CPO information 
20 can be provided. 

A test is then performed during step 4420 to determine if there are one or 
more operators excluded from the terms of the CPO. If it is detennined during step 
4420 that no operators are excluded from the customer's CPO. then the CPO 
management process 3600 continues operation as described above. If. however, ii is 
25 determined during step 4420 that one or more operators are excluded from the 
customer's CPO. then the CPO information is prefeiably transmitted to each specified 
and excluded operator daring step 4430. It is noted that the CPO can be provided to 
excluded operators before specified operators, or concunently. 

Any counteroffers are then received from the excluded operators during 
yo step 443S, and stored in the excluded operator counteroffer database 4300 during step 
4440. Each of the received counteroffeis are then presented to the customer 21 10 
during step 4445. A test is then peiformed during'step 44S0 to determine if the customer 
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21 10 accepts any of the counteroffers before the original CPO is accepted by any of the 
specified operators. If it is determined during step 4450 that the customer 21 10 does not 
accept any of the cotmteroffeis before the original CPO is accepted by any of the 
specified operators, then the CPO management process 3600 continues operation as 

s described above. 

If, however, it is determined during step 4450 that the customer 2 1 10 has 
accepted a counteroffer before the original CPO is accepted by any of the specified 
operators, then the original CPO is teiminated or cancelled and the status of the original 
CPO in the CPO database 2900, 4000 is changed to "cancelled" during step 4460. 
to Thereafter, the status of the accepted counteroffer is changed to "accepted" and the 
status of the rejected counteroffers, if any. are changed to "rejected" in the excluded 
operator counteroffer database 4300 during step 4465. Finally, program control returns 
to the CPO management process 3600 and continues in the manner described above. 

Although the post-sell multi-bind process 4200 and the excluded seller 
15 CPO evaluation process 4400 have been illustrated herein in a cruise embodiment, it is 
noted that the post-sell multi-bind process 4200 and the excluded seller CPO evaluation 
process 4400 are applicable in other industries as well, including the airline and other 
travel-related industries, the long distance telephone industry and the finance industry, 
as would be apparent to a person of ordinary skill. 
20 PACKAGE CPO MANAGEMENT SYSTEM 

A furOter embodiment of the present invention, suitable for processing 
the sale of packages of goods and services. Is discussed below in conjunction with 
Figures 45 through S7. Figure 45 shows a conditional purchase offer (CPO) 
Tnanagement system for receiving and processing CPOs fiom one or more buyers, 
25 utilizing buyer interfaces 4800. for packages of component goods o: services. In one 
embodiment, the package CPO management system 4500 deconstnicts or breaks up an 
overall package CPO into component CPOs which are individually offered to sellers. 
The package CPO management system 4500 processes the indivulual component CPOs 
associated with each package CPO to determine whether one or more sellers, utilizing 
30 seller interfaces 4801-4806, are wilting to accept each of the individual components of a 
given package CPO. As discussed funher below, if each of the individual component 
CPOs of a given package CPO are accepted by one or more sellers, the package CPO 
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management system 4500 binds the buyer, on behalf of each of the accepting sellers, to 
purchase the entire package. In this n)anner, a legally binding contract is formed. 

As used herein, a package CPO is a binding offer containing one or more 
conditions submitted by a 'buyer for the purchase of a package of component goods or 
S services or both, such as air travel, hotel and car rental, at a buyer-defmed price. In the 
illustrative travel embodiment, the buyer-defined conditions for a package CPO would 
generally include overall price and itinerary parameters, such as the origin and 
destination cities: acceptable dales and times of travel; and desired class of service for 
each individual component. In addition, a buyer may optionally provide more detailed 
10 specifications for one or mote individual components of an overall package CPO, such 
as whether connecting flights or stopovers are acceptable to the buyer for the airline 
ponion of a travel-related package CPO, or a preferred provider for one or more 
individual component goods or services. 

According to one feature of the present invention, the package CPO 
15 management system 4500 preferably deconstructs an overall package CPO into 
component CPOs which are individually offered to selleis. In an alternate embodiment, 
the package CPO management system 4500 provides the overall package CPO to each 
seller, with' sellers being able to separately accept each component of the package CPO. 
It is noted that the individual components of a package CPO can be for identical 
20 products. For example, a buyer can submit a purcha.« offer for six (6) general 
admission tickets to a particular sporting evenL The package CPO management system 
4500 can provide the purchase offer to sellers as an integral CPO for six tickets which 
mhy only be accepted by one seller. Alternatively, the package CPO management 
system 4S00 can deconsttuci the overall package CPO for six tickets into a number of 
25 component CPOs for one or more tickets which are individually offered to sellers. In 
one implementation, an overall package CPO for bulk goods can be decoasttucted into 
component CPOs which are optimized into units which ate most likely to be accepted. 
In the above ticket example, the package CPO managcmenf system 4500 can 
decompose the request for six tickets into three component CPOs for two tickets each. 
30 assuming that most sellers are looking to sell pairs of tickets. 

In one piefemed embodiment, the package CPO tiuuiagement system 
4500 reserves a margin off of the total ofTer price, before calculating the offer price for 
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each compcment CPO. The reserved margin amount may be determined based on the 
likelihood that all components of the overall package will be bound. In this manner, the 
margins mitigate the risk incurred by the package CPO management system 4S0O as a 
result of a failure to bind all components of a package CPO. 
} As discussed further below in conjunction with Figure 56, the package 

CPO management system 4500 can utilize the reserved margin or portions thereof to 
increase the offer price of one or more component CPOs that remain unaccepted by 
sellers. For example, if a buyer were to submit an offer for a vacation package with a 
total cost not to exceed one thousand dollars (SI, 000.00), the package CPO 
to management system 4500 may retain a one hundred dollar margin ($100), or ten percent 
(10%), to utilize if components of the desired package cannot be bound with the offer 
prices allocated from the initial $9(X). If, however, the package CPO management 
system 4500 is successful in binding the entire package with the initially allocated S900, 
then the package CPO management system 4S0O can retain the StOO margin as profit. 
t5 return the margin to the buyer, or place the unused margin in a fund to help bind the 
component CPOs of other package CPOs. 

In order to calculate an offer price for each component CPO, the package 
CPO management system 4S00 preferably initially determines the total market price of 
the package based on the market price of each individual component good or service 
20 within the package. The package CPO management system 4500 then calculates an 
offer price for each component CPO based on the total price offered by the buyer for the 
entire package, as adjusted by the reserved margin, if appropriate, multiplied by the 
ratio of the market price of the respective component CPO to the toul market price of 
the package. For example. If a buyer submits an offer for a travel package consisting of 
25 air travel, hotel accommodations and a car rental, with a total cost for the package not to 
exceed one thousand dollars ($1,000.00). and with each component item having a 
market price of $420, $400 and S2S0, respectively, the padcage would have a total 
market price of SI070. If a $1<X) margin is initially retained by the package CPO 
management system 45(X), the $900 adjusted package CPO price would be allocated to 
30 the individual component CPOs as follows based on the market prices: $360 (40%) for 
airline tickets, $333 (37%) for hotel acconunodations and $207 (23%) for car rental. 
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The package CPO management system 4500 then processes the 
individual componeni CPOs to deteimine whether one or more sellers are willing to 
accept each of the individual component CPOs of the overall package CPO. If 
successful, (he package CPO management system 4S00 binds the buyer, on behalf of 

5 each of the accepting sellers, to purchase the entire package. As discussed further 
below, as each individual component CPO is accepted by a seller, the package CPO 
management system 4500 preferably enters a "pre-bind" agreement with the seller, 
whereby the component good or service is reserved for a predefined time period to 
permit the package CPO management system 4S00 to complete the processing of the 

10 remaining active component CPOs. A seller who accepl.i! a component CPO may permit 
the package CPO management system 4500, for example, a two-week penod within 
which the package CPO management system 4500 must complete the package, li is 
noted that such a limited predefined "pre-bind* period protects sellers from reserving a 
product that cannot be later sold. 

IS In an alternate implemeniation, the package CPO management system 

4S00 can enter binding agreements with each seller who elects to accept a componeni 
CPO. In this implementation, if parts of the package were bound, and others were not at 
the time of expiration, the package CPO management system 4S0O could fund the 
difference to complete the unaccepted components of the package at or near market 

20 prices. In a further alternate implementation, the package CPO management system 
4300 can provide component CPOs to sellers in a particular serial order, based on the 
likelihood that each component of the package will bind. 

In addition, a seller can preferably be ensured that the package CPO 
management system 4500 could not continue shopping an accepted component CPO to 

25 the seller^ competitors after a pre-bind is obtained by encrypting the initial pre-bind. 
For example, a seller who pre-binds a given component CPO can encrypt their 
identifying characteristics before transmitting their acceptance to the package CPO 
management system 100 so that the package CPO management system 4500 can 
identify the seller's industry, stich as airline, and authorization to accept offers, but. 

30 could not identify the seller's specific identity until the entire package was complete. 

Although the package CPO management system 4S00 is illustrated 
herein as a system for processing travel-related package CPOs, the package CPO 
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management system 4500 could be utilized to process packages of any component 
goods or services or both, such as automobiles and related insurance, computers and 
related peripheral equipment, or bulk goods, as would be apparent to a person of 
ordinary skill. 

5 PACKAGE CPOMANAGEMEIVT SYSTEM 

As shown in Figure 45. the package CPO management system 4500 
preferably includes a cenual controller 4600 and one or more secured servers 4700, for 
communicating with one or more buyer or seller interfaces 4800-4806. The package 
CPO management system 4500 may provide a given component CPO to selected sellers 
10 based on the industry associated with the component CPO or other predefined screening 
criteria, as shown in Figure 45, so that sellers only obtain component CPOs thai they 
may be interested in or arc authorized to screen. Alternatively, the package CPO 
management system may provide all component CPO.^ lo all sellers for screening. 

According lo one feature of the present invention, the package CPO 
IS management system 4500 preferably provides an optional agency feature that permits 
the package CPO management system 4500 to accept or reject a given component CPO 
on behalf of ceitain agency-based sclleis who have delegated such authority to the 
package CPO management system 4500. Thus, the package CPO management system 
4500 preferably (i) evaluates component CPOs on behalf of certain agency-based sellers 
20 who have delegated authority to the package CPO management system 4500 to accept 
or reject a given component CPO, and (ii) perrnils broadcast-based sellers to evaluate 
component CPOs independently. Thus, the package CPO management system 4500 can 
preferably provide one or more component CPOs of a received package CPO to each 
broadcast-based seller, for the seller to independently determine whether or not to 
25 accept a given' component CPO. It is noted thai the package CPO management system 
4500 can provide a component CPO to each appropriate broadcast-based seller, for 
example, by means of a broadcast transmission, or by means of posting the component 
CPO, for example, on an electronic bulletin Board accessible by each broadcast-based 
seller. Alternatively, the package CPO management system 4500 can evaluate one or 
30 more component CPOs of a received package CPO against a number of CPO rules 
defined by one or more agency-based sellers, to decide on behalf of an agency-based 
seller to accept or reject a given component CPO. Thus. Ihe package CPO management 
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system 4500 can detennine if one or more sellers accepts a given componeni CPO by 
providing the component CPO to each seJIer and receiving an acceptance or rejection, or 
by applying the component CPO to the CPO rales to render a decision to either accept, 
reject or counter a component CPO on behalf of a particular seller. 
5 As discussed fuithcr below, a CPO rule is a set of lestrictions defined by 

a given agency-based seller, such as seller 4804. to define a combination of such 
restrictions for which the seller is willing to accept a predefined minimum price. In one 
embodiment, the CPO rules are generated by the revenue management system, yield 
management system, or profit management system of the respective agency-based 
10 seller, or by any system that controls and manages inventory. For a more detailed 
discussion of CPO rules, the manner in which they are generated and related security 
issues, see U.S. Patent Application Serial No. 08/889,3 19, entitled Conditional Purchau 
Offer Management System, filed July 8, 1997, the patent application to the present 
invention, which is incorporated by reference herein. Generally, the revenue 
15 management system, for example, will employ n CPO rules generation process to 
generate CPO rules by evaluating current inventory, pricing and revenue information, as 
well as historical patterns and external events, to foiecast future travel. 

For example, a CPO rule for a given agency-based airline can specify 
that the airline will accept any component CPO for travel between Newark. New Jersey 
20 (EWR) and Orlando, Florida (MCO) during the month of October, 1997, provided thai 
(i) the customer travels between Tuesday and Thursday, (ii) the tickets are booked 
widiin 21 days of depainire, (iii) the price is at least SI65 per ticket, (iv) K-class 
inventory is available on all flight segments of the customer^ itinerary, and (v) there are 
at least two (2) passengers travelling together. 
23 As discussed fuither below in conjunction with Figure 47, each secured 

server 4700 may be associated with one or more agency-based sellers and each server 
4700 stores, among other things, the CPO rules defined by any associated agency-based 
sellers, sutdi as sellers 4804 and 4806. Each secured server 4700 may be remotely 
located from the central controller 4600, as shown in Figure 45, or may be integrated 
30 with the central controller 4600. In one remote embodiment, the secured server 4700 
associated with each agency-based seller may be physically located at a processing 
facility secured by the particular seller, or at the physical location of a thitd pany. 
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As discussed fuither below, each buyer contacu the paclcage CPO 
nianagement system 4500, for example, by means of telephone, facsimile, online access, 
e-tnail, in-person contact or Uirough an agcni, and provides the package CPO 
management system 450O with the tetnis of their package CPO. h is noted that each 
s buyer may employ a general-purpose computer, such as the buyer interface 4800, 
discussed below in conjunctign with Figure 48, for communicating with the package 
CPO management system 4500. The general-purpose computer of each buyer is 
preferably comprised of a processing unit, a modem, memory means and any software 
required to communicate with the package CPO management system 4500. 
10 Once the terms of the package CPO have been received by the package 

CPO management system 4500, the central comroMer 4600 will execute a package CPO 
posting process S500, discussed below in conjunction with Figures 5Sa through S5c, to 
deconstruct the overall package CPO into component CPOs, and thereafter (i) provide 
each component CPO to the appropriate broadcast-based sellers and (ii) evaluate each 
IS component CPO against the appropriate CPO rules of each appropriate agency-based 
seller. In addition, once the con^)onent CPOs have been posted, the package CPO 
management system 4S00 will preferably periodically execute a package CPO 
monitoring process S600, discussed fiinher below in con)unction with Figures S6a 
through 56c. to determine if each component CPO of an overall package CPO is 
20 accepted by an appropriate sellin'. If each of the individual component CPOs of a given 
package CPO are accepted by one or more sellers, the package CPO management 
system 4S00 notifies the buyer, on behalf of each of the accepting sellers, that he ha<i 
been bound to purchase the entire package with the appropriate restrictions which meet 
the conditions defined by the buyer. 
2S The package CPO management system 4500 and buyer and seller 

interfaces 4800-4806 (collectively, the "nodes") preferably transmit digitally encoded 
data and other information between one another. The coimiuinication links between the 
nodes preferably comprise a cable, fiber or wireless link on which electrenic signals can 
propagate. For example, each node may be connected via an Intemct connection using 
30 a public switched telephone network (PSTN), such as those jvovided by a local or 
regional telephone operating company. Alternatively, each node may be connected by 
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dedicated data lines, cellular, Personal Communication Systems ("PCS"), microwave, or 
satellite networks. 

Figare 46 is a block diagram showing the architectuie of an illustrative 
central controller 4600. The central controller 4600 preferably includes ceitain standard 
5 hardware components, such as a central processing unit (CPU) 4605. a random access 
memory (RAM) 4510, a read only memory (ROM) 4620. a clock 4625, a data storage 
device 4630, an operating system 46S0, a payment processor 4660 and a network 
interface 4680. The CPU 460S is preferably linked to each of the other listed elements, 
either by means of a shared data bus, or dedicated connections, as shown in Figure 46. 
to The CPU 4605 may be embodied as a single commercially available 

processor, sufch as Intel's Penlium 100 MHz P54C microprocessor, Motorola's 120 MHz 
PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UltraSPARC-l 
microprocessor. Alternatively, the CPU 460S may be embodied as a number of such 
processors operating in parallel. 
IS The ROM 4620 and/or data storage device 4630 are operable to store one 

or more instructions, discussed further below in conjunction with Figures 55 and 56, 
which the CPU 4605 is operable to retrieve, interpret and execute. The payment 
processor 4660 preferably implements known processes to accomplish the transfer of 
'required payments, charges and debits, between the sellers and buyers, by means of a 
20 conventional electronic funds transfer (EFT) network. In particular, as discu.sscd below 
in conjunction with Figure 56. the package CPO monitoring process 5600 preferably 
transmits the credit card information associated with a given buyer to the credit card 
issuer for payment, if a package is actually purchased by the buyer. The processing of 
such accounting transactions are preferably secured in a conventional manner, for 
2S example, using well-known cryptogrq)hic techniques. 

The CPU 4605 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackablc 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from the data storage device 4630 or ROM 4620. The ALU is 
30 operable to perform a plurality of operations needed to cany out instmctions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
tempotary results and control information. 
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As discussed further below in conjunction with Figures 49 through 53, 
respectively, the data storage device 4630 includes a buyer database 4900, a seller 
database 5000, a package C3>0 database 5100, a component CPO daubase 5200 and a 
market price daubase 5300. The buyer database 4900 preferably stores information on 
5 each buyer of the package CPO. management system 4S0O, including biographical 
information and billing information, such as a credit card number. The seller database 
5000 preferably stores infomiaiion on each seller which is legistered with the package 
CPO management system 4500 to sell component goods or services to package CPO 
buyers, including identifier and name information. The package CPO database SlOO 
10 preferably contains a lecord of each package CPO being processed by the package CPO 
management system 4500, including an indication of the component CPOs within each 
package CPO and the associated status. The component CPO databa.sc 5200 preferably 
contains a record of each component CPO being processed by the package CPO 
management system 4500. including the term.? of each component CPO and the 
IS as.sociaied status. Finally, the market price database 5300 preferably stores market price 
information for each component good or service processed by the package CPO 
management sy.stem 4500. 

In addition, the data storage device 4630 includes a package CPO posting 
process 5500 and a package CPO monitoring process 5600. discussed further below in 
20 conjunction with Figures 55 and 56. respectively. Generally, the package CPO posting 
process 5500 deconsmicts the package CPO into component goods or services, and 
(hereafter (i) posts each component CPO to the appropriate broadcast-based sellers and 
(ii) evaluates each component CPO against the appropriate CPO rules of each agency- 
based seller. The package CPO monitoring process 5600 determines if each component 
23 CPO of a posted package CPO is accepted by an appropriate seller and. if accepted, 
provides buyer infoimation to each accepting seller. In this manner, if each of the 
individual component CPOs of a given package CPO are accepted, the package CPO 
nuDiagemem system 4500 notifies the buyer, on behalf of each of the accepting sellers, 
that he has been bound to purchase the entire package. 
30 The network interface 4680 connects the central controller 4600 to the 

buyer and sellers, for example, by means of an Internet connection using the public 
switched telephone network (PSTN), fife netwoilc interface 4680 preferably includes 
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multiple coimnunicaiion channds for simultaneously establishing a plurality of 
connections. 

Figure 47 is a block diagram showing the architecture of an illustrative 
secured server 4700. As pieviously indicated, the package CPO management system 
5 450O may utilize one or more secured servers 4700, each supporting one or more 
agency-based sellers 4804. 4806. Each secured server 4700 preferably includes cenain 
standard hardware components, such as a central processing unit (CPU) 4705. a random 
access memory (RAM) 4710. a read only memory (ROM) 4720, a clock 472S, a data 
storage device 4730, and a communications port 4740. Each of these components may 
10 be identical to those described above in conjunction with Figure 46. 

As previously indicated, in one embodiment, the CPO rules may be 
stored in a secure database to maintain the integrity and conndentialiiy of the ht^ly 
sensitive information included in each CPO rule. Thus, the secured server 4700 
pivferably uses a secure database, such as the products commercially available from 
IS Oracle. Informix or IBM. 

As discussed further below in conjunction with Figure 54, the data 
storage device 4730 includes a secured seller mles database 5400. The secured seller 
rules database 5400 preferably maintains the CPO rules for the one or more agency- 
ba.sed sellers associated with the secured server 4700. As previously indicated, the 
20 secured seller rules database 5400 may be stored in an encrypted formal to maintain the 
integrity and confidentiality of the highly sensitive information included in the CPO 
rules. In addition, the data storage device 4730 includes a component CPO rule 
evaluation process 5700, discussed further below in conjunction with Figure S7. 
Generally, the component CPO rule evaluation process 5700 is a subroutine executed by 
25 the package CPO posting process SSOO, which receive; a component CPO and 
compares the CPO against the lules of one or more agency-based sellers to generate a 
response on behalf of the sellers to the given component CPO. 

The secured server 4700 may optionally maintain an audit trail for each 
component CPO that is processed by the package CPO management system 4500. For a 
30 discussion of a suitable audit system, see the patent application to the present invention, 
incorporated by reference herein above. 
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The communications pon 4740 connects the secured server 4700 to the 
central controller 4600. The coininunications pon 4740 preferably includes multiple 
communication channels for simultaneously establishing a plurality of connections. 

Figuie 48 is a block diagram showing the architecture of an illustrative 
5 buyer or seller interface 4800-4806. The interface 4800 preferably includes certain 
standard hardware components, such as a central processing unit (CPU) 4808, a random 
access memory (RAM) 4810, a lead only memory (ROM) 4820, a clock 4825, a data 
storage device 4830. and a communications port 4g40. Each of these components may 
be identical to those described above in conjunction with Figure 46. In addition, the 
10 interface 4800 preferably include.<> a video monitor 4830 and related video driver 4860. 
and an input device 4870. such as a keyboard or mouse. 

The data storage device 4830 preferably includes a message databa.<e 
4880 for storing messages required by the respective buyer or seller interface 4800-4806 
to communicate with the central controller 4600 of the package CPO managcmeni 
13 system 4500. The communications port 4840 connects the Interface 4800 to. the ccnlral 
controller 4600 or the secured server 4700, for broadcast-based and agency-based 
.sellers, respectively. 

Figure 49 illustrates an exemplary buyer databarw 4900 thai preferably 
stores information on each buyer of (he package CPO management .system 4S00, 
30 including biographical information and billing information, such as a credit card 
number. The buyer database 4900 maintains a plurality of records, such a.s tecord.s 
490S-491S. each associated with a different buyer. For each buyer identifier in field 
4920, the buyer database 4900 includes the comsponding buyer name and address in 
fields 4925 and 4930, respectively, and credit card number in field 4935. In addition. 
25 the buyer database 4900 preferably includes an indication of the CPOs associated with 
the buyer in field 4940. which may be package CPOs as described lietein or general 
CPOs as described in the parent application to ihe present invention. The identifier 
stored in field 4920 may be utilized, for example, to index a historical database (not 
shown) of previous purchases and CPOs associated with the buyer. 
30 Figure SO illustrates an exemplary seller database 5000 which preferably 

stores information on each seller which is registered with the package CPO management 
system 4500 to sell component goods or services to package CPO buyers, including 
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identifier and name infoimation. The seller database 3000 maintains a plurality of 
records, such as records 5005-5030, each associated with a different seller. For each 
seller itjentifier listed in field S03S, the seller database 5000 includes the conesponding 
seller name in field 5040. In addition, the seller database 5000 preferably records a 
S tracking number in field S04S for any CPOs associated with each seller. It is noted that 
the information recorded in field 5045 could be similarly recorded by including a seller 
ID field in the package CPO database 5100, discussed below. 

Figure 51 illustrates a package CPO database 5100 which preferably 
contains a record of each package CPO being processed by the package CPO 
10 tiumagement system 4SQ0, including an indication of the component CPOs within each 
package CPO and the associated status. The package CPO database 5100 maintains a 
plurality of records, such as records 5105-51 10. each associated with a different 
package CPO. For each package CPO listed in field S 1 20. the package CPO database 
SIOO includes the status and original offer price in fields SI 25 and 3130. icspeciively. 
IS In addition, the package CPO database SIOO preferably records the margin factor, 
remaining margin, adjusted package CPO price and per-allocation-niargin percentage in 
fields S13S through 5150. respectively. The manner in whicli the margin variables are 
processed by the package CPO management system 4S00 arc discussed below in 
ccnjunaion with Figure 56. The posting and expiration dates of the package CPO, as 
20 well as the total posting duration period and posting lime required for each margin 
allocation are stored in fields 5I5S through 5170, respectively. The individual 
component goods or services within each package CI>0 ate optionally identified in field 
S17S, and the conditions and component numbers associated with each component are 
set forth in fields 51 80 and 5185. It is noted that the information recorded in fields 5)75 
23 and 5 1 80 could alternatively be retrieved from the component CPO database 5200 using 
the component CPO numbeis recoided in field S 185. Finally, an identifier of the buyer 
associated with each package CPO is prefetably lecofded in field 5 190. 

Figure 52 illustrates afi exemplary component CPO database 5200 which 
preferably contains a record for each component CPO being processed by the package 
30 CPO management system 4500, including the terms of the component CPO and the 
associated status. The component CPO database 5200 maintains a plurality of records, 
such as records 5205 through 3230, each associated with a diffetejit comjponent CPO 
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being processed hy the system 4500. For each component CPO identiried by 
component CPO number in field S240, the component CPO database S200 includes the 
status or expiration date for pre-bonnd component CPOs in field 5245, as well as the 
corresponding subject, ptice and conditions associated with the component CPO in 
. 5 fields 5250 through 5260, respectively. Finally, an identifler of the buyer associated 
with each component CPO is preferably recorded in Held S26S. 

Figure 53 illustrates an exemplary tnarlcei price database 5300 lhai 
preferably stores market price information for each component good or service 
processed by the package CPO management system 4500. As discussed further below 
10 in conjunction with Figure 55. the package CPO posting process 4500 preferably 
utilizes the maricet price information to aU'ocale the overall package price to each 
component good or service. The maricet price database 5300 maintain.s a plurality of 
records, such as records 5305 through S34S. each associated with a different componcnl 
good or service processed by the sysunn 4500. For each component good or service 
IS identiried in field 5360. the market price databLse 5300 identifies the available quality 
or service levels for each good or service In Twld 5365. as well as the corresponding 
market price set forth in field 5375, for each time period indicated in Held 5370. It is 
noted that the market price for each service level of routxl trip airline travel is preferably 
recorded for each originating and destination city pair (O & D Pair). 
20 As previously indicated, the secured server 4700 preferably maintains 

one or more secured seller rules databases 5400 to store the CPO rules for the one or 
more agency-based sellers associated with the secured server 4700. An example of a 
secured seller rules database 5400 is shown in Figure S4a for an agency -based airline 
and in Rgure 54b for an agency -based hotel. 
23 Figure S4a illustrates an exemplary seciued airline rules database 5400 

which prefer!d>ly maintains the CPO roles for one or more agency-based airlines 
associated with a panicular seciued server 4700. As previously indicated, the secured 
airline rules database 5400 may be stored in an encrypted format to maintain the 
integrity and confidentiality of the highly sensitive information included in the CPO 
30 rales. The secured airline rules database 5400 maintains a pluialtty of records, such as 
lecoids 5402 and 5404. each associated with a different CPO role. For each CPO rule 
identified by rule number in field 5410; the secured airline rules database S400 includes 
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the associated restrictions defined by the respective agency-based airiine in ftelds 54 12 
through 5444. 

Figure S4b illustrates an exemplary secured hotel roles database 3450 
which preferably maintains the CPO rules for 'one or more agency-based hotels 
5 associated with a particular secured server 4700. As previously indicated, the secured 
hotel rules database S4S0 may be stored in an encrypted format to maintain the integrity 
and confidentiality of the highly sensitive information Included in the CPO rules. The 
secured hotel rules database 5450 maintains a plurality of records, such as records 5452 
through 5456, each associated with a different CPO rule. For each CPO rule identified 
10 by lule number in field 5460, the secured hotel rules database 5450 identifies the 
applicable hotel sites in field 5465 and includes the associated restrictions defined by 
the respective agency-based hotel in fields 5470 through 5490. 

As discussed above, the central controller 4600 preferably executes a 
package CPO posting process 5500, shown in Figures S5a through 55c, to deconstmci 
IS the package CPO into component goods or services, and thereafter (i) post each 
component CPO to the appropriate broadcast-based sellers and (10 evaluate each 
ctmtpoiieiu CPO against the appropriate CPO nilcs of each agency-based seller. As 
illusuaied in Figure SSa, the package CPO posting process SSOO begins the processes 
embodying the principles of the present invention during step SSOS. when a buyer 
20 submits a CPO for a package of component goods or services. 

Thereafter, the central controller 4600 will receive the conditions 
asiiociaied with the package CPO from the buyer, including a description of each 
component good or service, and an identifier of a general purpose account, .such as a 
credit or debit card account from which funds may be paid during sicp 55 10. and then 
23 receive the price and expiration date for the package CPO from the buyer during step 
S5 IS. In this manner, the offer is guaranteed with a general purpose account, for 
example, using a line of credit on a credit card account. Appropriate legal language is 
preferably displayed or read to the buyer during step SS20 to form a bmding package 
CPO. A package CPO number is generated during step 5525, and the package CPO 
30 information, including the buyer identifier, package CPO price and expiration date, and 
conditions for the component goods or services, is then entered into the package CPO 
database 3100 during step SS30. 
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As previously indicated, the package CPO management system 4500 
preferably reserves a margin off of the total package offer price, before calculating the 
offer price for each component CPO. Thus, an appropriate margin is 'calculated during 
step 5535 by multiplying the paclcage CPO price by the margin factor lecorded in the 

5 package CPO database 5100. Thereafter, the calculated margin is recorded in the 
"remaining margin" field 5140 of the package CPO database 5100 during step 5540 
(Figute 55b). The adjusted CPO price is then calculated by subtracting the calculated 
margin from the original total paclcage offer price, which is then entered into the 
package CPO database 5 100 during step 5545. Tbe status of the package CPO is set to 

10 "active" in field 5 125 of the package CPO database 5 1 00 during step 5550. 

The market price of each component good or service in the package CPO 
is retrieved during step 5555 from the market price database 5300. The market price of 
the overall package CPO is calculated during step SS60 by adding the market price of 
each individud component CPO in the overall package. The individual CPO prices for 

15 each coinponent CPO are then calculated during step 5565. for example, by allocating 
the adjusted package CPO price, as calculated during step 5545, in accordance with the 
ratio of the market price of the respective coinponent good or service to the total market 
price. 

A CPO number Is then generated for each component CPO during step 
20 5570 and recorded in the "componeni CPO numbers" field of the package CPO database 
5100 during step 5575 (Figure 55c). A new record is created in the component CPO 
database S200 for each component CPO during step SS80. before each component CPO 
is provided to each broadcast-based seller and the component CPO rule evaluation 
process 5700 is executed for each agency-based seller during step 5590. Program 
25 control terminates during step 5595. 

As discussed above, the central controller 4600 preferably executes a 
package CPO monitoring process S600, shown in Figures S6a through S6c, to determine 
if each componeni CPO of a posted package CPO has been accepted by an appropriate 
seller and, if accepted, provides buyer information to each accepting seller. In this 
30 manner, if each of the individual component .CPOs of a given package CPO arc 
accepted, the package CPO management system 4300 notiries and binds the buyer, on 
behalf of each of the accepting sellers, to purchase the entire package. The package 
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CPO monitoring process 5600 may be periodically executed to determine the status of 
each component CPO, or executed continuously. 

As illustrated in Figure S6a, the package CPO monitoring process S600 
begins the processes embodying the principles of the present invention diuing step 

5 5605, by performing a test to determine if all of the component CPOs within a given 
pacicage CPO have been prc-bound at currently posted prices. It is noted that in the 
illustrative embodiment, the first seller to accept a given component CPO is awarded the 
component CPO. For a discussion of other mechanisms for determining which seller 
among a plurality of accepting sellers should be awarded a component CPO, see the 

10 parent application to the present invention, incorporated by reference herein above. If it 
is determined during step 5605 that all of the component CPOs within a given package 
CPO have been pre-bound at currently posted prices, then buyer identification 
information, including the buyer); name, address and credit card account number, is 
retrieved from the buyer database 4900 during step 5650. Thereafter, the buyer 

IS identification number is uansmitted lo each seller who accepted a component CPO 
during step 5655. The package CPO monitoring process 5600 transmits the merchant 
identifier of the package CPO management .system 4300. together with the buyer's 
credit card account number, a billing descriptor and the purchase- amount for the 
package CPO to the credit card issuer for payment authorization during step 5660. via a 

20 conventional credit card authorization network. 

The status field 5125 of the package CPO database 5100 is updated 
during step 5665 to indicate that the respective package CPO was completed, before 
program control tenninates ihiring step 5670. 

If, however, it was determined during step 5605 that all of the component 

25 CPOs within a given package CPO have not been pre-bound at currently posted priceji. 
then the expiration date of the package CPO is retrieved from field 5 1 60 of the package 
CPO database 5 100 during step 5610 (Figure S6b). A test is then perfoimed during step 
5615 to determine if the package CPO has expired. If it is determined during step 56 IS 
that the package CPO has expired, without each component being pre-bound. then the 

30 package CPO monitoring process 5600 communicates (1) termination of any pre-bind 
agreements for component CPOs within the expired package CPO which were accepted 
by one or more sellers to the respective sellers during step 5635; and (1 1) expiration of 
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the package CPO to the respectivetbuyer during step 5640. In an alternate embodiment, 
the buyer can be invited to lesubmit a revised package CPO if the original package CPO 
is not accepted. In addition, the package CPO inanagement system 4500 might attempt 
to compile a counteroffer for the buyer, based on acceptances of individual components 
5 received by the package CPO management system 4500. Thereafter, program control 
terminates during step 5645. 

If. however, it is determined during step 5615 that the package CPO has 
not expired, then the package CPO monitoring process 5600 will adjust the status field 
SI2S of the package CPO database 5100 during step S620 to indicate the percentage of 
10 the overall package CPO which is currently pre-bound, for example, by accessing the 
package CPO database SlOO to identify the number of components in the package CPO, 
and identifying the number of components which ate currently pre-bound.. Thereafter, 
the "total posting duration" parameter is retrieved from field 5165 of the package CPO 
database 5100 during step 5625, which is then multiplictl by ihe "posting lime required 
IS for each margin allocation" parameter set fonh in field 5170. 

A lest is then performed during step 5630 to determine if the package 
CPO has been active for the posting time lequited to allocate additional margin to 
increase the price of each component CPO which has not yet been pi«-bound. If it is 
determined during step 5630 that the package CPO has not been active for the posting 
20 time required to allocate additional margin, then program control returns to step 5605 
(Figure 56a) and continues processing in the manner described above. If. however, it is 
determined during step 5630 thai the package CPO has been active for the posting time 
tequiicd to allocate additional margin, then the percent composition of each remaining 
active component CPO is calculated during step 5675 (Figure 56c) relative to the total 
25 price of all remaining active component CPOs. 

The "per allocation margin percentage" is then retrieved during step 5680 
from field 5150 of the package CPO database 5100. The amount of margin to be 
allocated to remaining active component CPOs is then calculated during step 5682 by 
multiplying the retrieved "per allocation margin percentage" value by "remaining 
30 margin" value recorded in field 5140 of the package CPO database SlOO. Thereafter, 
the allocable margin is qiplied to each remtoning active component CPO in appropriate 
"petcentages during step S6B4 by mulUplying the price percentages of the remaining 
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active component CPOs (as determined during step 5675) by the calculated allocable 
margin amount. 

For example, if one component of a three component package is initially 
pre-bound at the originally posted price, and the remaining two components are not 

5 bound within the posting time required to allocate additional margin, then the package 
CPO monitoring process 5600 preferably allocates part of the margin between the two 
remaining component CPOs. The arnount allocated lo each component CPO is 
preferably determined by their respective initially posted prices. Assume in the 
example discussed above, where a buyer submits an offer for a travel paclcage 

10 consisting of air travel, hotel accommodations and a car rental, with a total cost for the 
package not to exceed one thousand dollars ($1,000.00), that the first component to 
piebind was the airline tickets at $360. Thus, the package CPO monitoring process 
S600 will allocate a portion of the remaining margin to the offer prices for the hotel and 
car rental component CPOs. In a preferred embodiment, since the hotel component 

15 CPO accounts for 62% of the total remaining CPO prices ($333/(5333 + S207)), the 
offer price of the hotel component CPO is increased by 62%, or $3 1, of the money taken 
from the margin (SSO). Likewise, the car lental component CPO offer price would be 
increased by 38% or $19. If one' or more components are again not bound for the 
posting time'required to allocate additional margin, more of the margin is preferably 

20 allocated. 

The "remaining margin' recorded in field 5140 is adjusted during step 
S688 by subtracting the margin allocated in the previous step. Thereafter, during step 
SS90. the remaining active CPOs with the newly adjusted prices are piovided to 
broadca<it-based sellers and the componeni CPO rule evaluation process S700 is 

25 executed for each appropriate agency-based seller. Finally, program control returns m 
step S60S (Figure S6a] and continues processing in the manner described above, until all 
component CPOs are pre-bound, or until the package CPO expires. In this manner, the 
offer prices ate increased with additional alkxated margin for each coniponem CPO that 
remains unaccepted for each time period required to allocate additional margin. As 

30 discussed above, the package CPO posting process 5S0O and the package CPO 
monitoring process 3600 each execute a component CPO rule evaluation pitxxss , 
during steps SS90 and S690, tespeaively, for agency-based sellers to compare the 
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component CPOs against the rales of one or more agency-based sellers to generate a 
response on behalf of the sellers to the given component CPO. An illustrative 
component CPO rule evaluiltion process 4700 is shown in Figure S7. In one 
embodiment, the component CPO rule evaluation process 5700 is customized for each' 
5 agency-based seller, so that each evaluation process 5700 receives the component CPO 
record from the central controller 4600 in a standard format for comparison against the 
lules of the associated seller, and returns a standard response of the seller to the 
component CPO, such as "accept" or "reject." 

As shown in Figure S7, the component CPO rule evaluation process 5700 
10 initially identifies all CPO rules in the secured seller mies database 5000 which are 
peninent to the component CPO during step 5710. Thereafter, during sicp 5720. the 
buyer defmed conditions from the component CPO record in the component CPO 
database 5200 arc then compared to the cornsponding seller defined nsiriciions from 
the secured seller rules database 5000 during step 5720, for each CPO rule identified 
IS during the previous step. 

Thereafter, a lest is performed during step 5730 to determine if the 
component CPO satisfies a CPO rule. If it is determined during .step 5730 that the 
component CPO does not satisfy one CPO lulc, then program control terminates during 
' step 5770. If. however, it is determined during step 5730 that the component CPO does 
20 satisfy a CPO rule, then the component CPO number is retrieved from the component 
CPO database 5200 during step 5740. and then entered into the "CPO tracking number" 
field 5045 of the seller database SOOO. The status of the component CPO in field S24S 
of the component CPO database 5200 is updated to "pre-bind completed" during step 
5760, before program control terminates during step 5770. In addition, a pre-bind 
2S expiration date can be added to field 5245, if mandated by the seller. 

CPO MANAGEMENT SYSTEM FOR TELEPHONE CALLS 
A further embodiment of the present invention, suitable for processing 
puidiase offers for one or more telephone calls, is discussed below in conjunction with 
Figures 58 through 66. Figures 58A and 58B show a conditional purchase offer (CPO) 
30 maiuigenKnt system 5800 for receiving and processing CPOs for telephone calls from 
one or more calling panies, such as calling pany 5810. The CPO managensent system 
S800 processes the CPO to detemuDe whether one or mote long distance caniets, such 
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as imerexchangc carriers 5820-SB24. are willing to accept a given CPO and complete a 
telephone call in accordance with restrictions defined by the calling party S810. In the 
United States, for example, the inteiexchange carriers 5820-5824 may be AT&T, Sprint 
and MCI. As discussed further below, if an inierexchange carrier 5820 accepts a given 
5 CPO. the CPO management system 5800 biniis the calling pany 58 1 0 on behalf of the 
accepting imetexcbange canier S820, to form a legally binding contract. 

As used herein, a CPO is a binding offer containing one or more 
conditions, submitted by a calling party 5810 for the completion of one or more 
telephone calls, typically at a price defined by the calling party. In this manner, a 
10 calling party 5810 can preferably submit a CPO for an individual telephone call, a 
package of calls to one or more called parties 3830, or for a contract to provide 
telephone service for a predefined period of time. In the illustrative embodiment, the 
conditions defined by the calling party 5810 may include the telephone number to he 
called, the maximum price, one or more preferred carriers, if any, as well as any time 
IS limitations. stKh as a particular lime-of-day or mininium call duration. The maximum 
price may preferably be specified by the calling party 5810 in terms of a price for a 
fixed period of time, such as ten dollars (S 10) for a twenty (20) minute telephone call, or 
in terms of a rate-per-minute, such as fourteen cents per minute ($0. 14/minuie). 
CPO MANAGEMENT SYSTEM 
20 Figure 58A shows an illusiraiive neiwork environment for 

interconnecting the CPO management system 580O with one or more calling parties 
S810 and one or more inteiexchange carriers 5820-S824 who may route a call to a 
desired called pany 5830. According to a feature of the present invention, a calling 
party 5810, desiring to call a called pany 5830. typically identified by a Plain Old 
2S Telephone Service (POTS) telephone number, may submit an offer to the CPO 
management system 5800 for a telephone call in accordance with restrictions defined by 
the calling paity. In one ptefetied implementation, the calling party SBIO uses a 
telephone set 5900, shown in Figure 59, to dial the telephone number assigned to the 
CPO management system S800, such as a toll-free telephone number, or "800 number," 
3D before dialing the telephone number of the called party 3S30 to provide the CPO 
management system 3800 with the terms of the CPO. Alternatively, the calling party 
3810 can initially contact' the CPO management system 5800 by means of facsimile. 
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Once the calling paity 58 10 initially contacts the CPO managenKnt system 5800. the 
calling party 5810 then submits (he terms of the CPO to the CPO management system 
5800, such as the maximum price for the call and the telephone number of the called' 
party 5830. 

5 In a further variation, shown in Figure S8B, the calling party 5810 can 

initially contact the CPO management system S80O by means of online access or e-mail 
using a subscriber termiaal 5815, such as a general-purpose computer, lo access the 
Internet 5870. This online embodiment is particularly suited for a calling party 5810 
desiring to submit a CPO for a package of calls to one or more called parties 5830, or 

10 for a contract to provide telephone service for a predefined period of time. 

The terms of (he CPO may optionally be displayed to the calling pany 
5810 on the telephone set S900, as shown in Figure 59. In addition, the telephone .<iei 
5900 can be specially configured with software for transmitting a CPO to the CPO 
management system 5800 or directly to the intcicxchange carrien 5820. For exan^le. a 

IS speed dial button of the telephone set 5900 can be programmed to automatically 
transmit the terms of a CPO to the CPO management system 5800 or directly to the 
inteiexchange carriers 5820. in this manner, the calling pany 5810 would program the 
terms of a given CPO using the keypad and function keys on the telephone set 5900, 
and then initiate transmission of the CPO using the speed dial button. 

20 As shown in Figure 58A, when the calling party 5810 dials the telephone 

number assigned to the CPO ntanagemenc system 5800. a connection is typically first 
established to a local switch operator 5850. which is the telephone switching system, for 
example, of the local telephone company. The local switch operator S8S0 in turn 
connects the callins party to the Public Switched Telephone Network (PSTN). The local 

25 switch operator 5850 is capable of establishing a connection between the calling party 
5810 and one of a number of intercxchangc carriers 5820-5824 over a communications 
link 5860, in a manner well-known in the telephony art. The mterexchange carriers 
S820 may be, for example, providefs of long distance carrier networks, including circuit 
and packet switched networks or combinations thereof, and the communications link 

10 5860 may be a cable, flbcf or wireless link on which electronic signals can propagate. It 
is noted that with the increasing trend for kng distance carriers to provide local 
telephone service in many areas, and vice versa, the distinction between the local switch 
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operator 5850 and ihe interexchange carriers 5820-5824 may become transparent. One 
or more of the interexchange carriers 5820 may be able lo route a call between a given 
calling party S810 and a desired called patty S830. For a moie detailed discussion of 
the manner in which a connection is made between a given calling party S8I0 and a 

5 desired called party 5830, over a long distance carrier network by an interexchange 
carrier 5820. see U.S. Patent Number 4,191 ,860, incorporated by reference herein. 

According to a feature of the present invention, the CPO management 
system 5800 preferably provides an optional agency feature that peimits the CPO 
management system S800 to accept or reject a given CPO on behalf of certain agency- 

10 based interexchange carriers 5820 who have delegated such authority to the CPO 
management system 5800. Thus, the CPO management system 5800 preferably (i) 
evaluates CPOs on behalf of certain agency-ba.sed interexchange cairiers 5820 who 
have delegated authority for deciding to accept or reject a given CPO to the CPO 
management system 5800; and (ii) permits broadcast-based interexchange carriers 5820 

IS 10 evaluate CPOs independently. Thus, the CPO management system 5800 can provide 
a CPO to each broadcast-based interexchange carrier 5820. for the interexchange carrier 
5820 to independently deiemiine whether or not to accept a given CPO. It is noted that 
the CPO managemeni system 5800 can provide a CPO to each broadcast-based 
interexchange carrier 5820, for example, by means of a broadcast transmission, or by 

20 means of posting the CPO, for example, on an electronic bulletin board accessible by 
each broadcast-based interexchange carrier 5820. 

In addition, the CPO managemeni system 5800 can evaluate a CPO 
against a number of CPO rules defined by one or more agency-based interexchange 
carriers 5820, to decide on behalf of an agency-based interexchange carrier 5820 to 

25 accept or reject a given CPO. Thus; the CPO management system 5800 can determine if 
one or more carriers accepts a given CPO by providing die CPO lo each carrier and 
receiving an acceptance or rejeciioa, or by applying the CPO to the CPO rules to tender 
a decision to either accept, reject or counter a CPO on behalf of a particular carrier. 

As discussed further below, a CPO rule is a set of resuictions defined by 

30 a given agency-based interexchange carrier 5820, to deTme a combination of such 
lesnictions for which the interexchange carrier 5820 is willing to accept a commitment 
to complete one or more telephone calls. In a ^refeired embodiment, the CPO rules are 
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geneiated by some type of revenue management system, yield management system, or 
profit management system of the respective agcnty-based interexchange carrier 5820, 
or by any system that controls and manages network capacity. For a more detailed 
discussion of CPO rules, the manner in which they aie genetated and related security 

5 issues, see U.S. Patent Application Serial No. 08/889,3 1 9, entitled Conditional Purchase 
Offer Management System, filed July 8, 1997, the parent application to the present 
invention, which is incorporated by reference herein. Generally, the revenue 
management system, for example, will employ a CPO niles generation process to 
generate CPO rules by evaluating current network capacity, pricing and revenue 

10 information, as well as historical patterns and external events, to forecast future calling 
demand. 

Once the terms of a CPO have been received by the CPO management 
system S800. a central server 6000, discussed below in conjunction with Figure 60. will 
execute a CPO management process 6500, discussed below in conjunction with Figures 
IS 65a and 65b, to (i) provide each CPO to the interexchange carriers 5820 and (ii) u> 
determine if the terms of the offer have been accepted by any interexchange carrier 
5820. Thereafter, the CPO manasement system 5800 or the accepting interexchange 
carrier S820 notifies the calling party 38 ID of the response of the interexchange carriers 
5820 and. if accepted, the calling party 5810 is bound to complete and pay for one or 
20 more calls having the appropriate testriaions which meet the conditions defined by the 
calling party 5810. 

The CPO management system 5800 may optionally maintain an audit 
tcail for each CPO that is processed by the CPO management system 5800. For a 
discussion of a suitable audit system, see the pareni application to the piescnt invention. 
25 incorporated by reference herein above. 

According to a fuither feature of the invention, the CPO management 
system 5800 prevents calling panics 5810 from identifying the cairier's minimum price 
for the one or more telephone calls associated with a given CPO. For example, the CPO 
management system 5800 preferably does not disclose the carrier's minimum price to 
30 calling parties and optionally limits the number of CPOs that any calling party 58 1 0 can 
submit within a predefmed time period. In addition, the binding nature of the present 
invention discourages calling parties 5810 from submitting CPOs merely to identify the 
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minimum price, since the calling party 5810 will be obligated to complete one or more 
telephone call(s) in accordance with the terms of the CPO. In altemaic embodiments, 
the calling party S810 can be charged a fee or a penalty if a call is not completed when 
at least one carrier 5820 has accepted the CPO, or the CPO management system 5800 
5 can evaluate a rating of the calling party 5810 containing information regarding the 
likelihood that the calling party 5810 will complete one or more telephone calls 
corresponding to said CPO. For a more detailed description of a suitable rating system, 
see U.S. Patent Application Serial No. 08/811,349, filed Match 4, 1997, entitled 
AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the 

to present invention and incorporated by reference herein. In one embodiment, the 
evaluated rating comprises a ratio of completed calls to purchase offcis by the customer 
5810. In thi.<i manner, the carriers 5820 can be confident that If the carrier accepts the 
calling party's offer, the calling party 5810 will complete the call(s) without using the 
information to asccaain the carrier's underlying level of price nexibiilly. 

'S Figure 60 is a block diagram showing the architecture of an illustrative 

CPO management central server 6000. The CPO management central server 6000 
preferably includes certain standard hardware components, such as a central processing 
unit (CPU) 6005. a random access memory (RAM) 6010. a read only memory (ROM) 
6020, a clock 6025, a data storage device 6030, and a communications port 6040. The 

2U CPU 600i5 is preferably linked to each of the other listed elements, either by means of a 
shared data bus, or dedicated connections, as shown in Figure 60. The CPU 6005 may 
be embodied as a single commercially available processor, such as Intel's Pentium 100 
MHz PS4C miciopiocessor. Motorola's 120 MHz PowerPC 604 microprocessor or Sun 
Microsystem's 166 MHz UltraSPARC-1 microprocessor. Alternatively, the CPU 6005 

25 may be embodied as a number of such processors operating cooperatively. 

The ROM 6020 and/or data storage device 6030 arc operable to store one 
or more instnictions. discussed further below in conjunction with Figures 65 and 66. 
which the CPU 6005 is operable to retrieve, intetpret and execute. For example, the 
ROM 6020 and/or data storage device 6030 preferably store processes to accomplish the 

30 transfer of required payments, charges and debits, between the calling parties 58 1 0 and 
intecexchange carriers 5820-5824. 
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The CPU 6005 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackable 
cache or a plurality of registers, in a known litanncr. The control unit is operable to 
retrieve instructions from the data storage device 6030 or ROM 6020. The ALU is 

5 operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 

As discussed further below in conjunction urith Figures 61 through 64, 
respectively, the data storage device 6030 preferably includes a customer database 

10 6100. a carrier database 6200, a rate database 6300, and a CPO database 6400. The 
customer database 6100 preferably .stores information on each customer of the CPO 
management system S800, including biographical information and an indication of the 
local telephone company serving each customer. The carrier database 6200 preferably 
stores information on each carrier which is registered with the CPO management system 

15 5800 to provide long distance telephone .service to calling panics, including addrc.is 
information. The rate database 6300 preferably stores published rate information for 
each carrier identified in the carrier database 6200. Fmally, the CPO database 6400 
preferably contains a record of each CPO being processed by the CPO management 
system 5800, including the terms of the CPO and the associated status. 

20 In an embodiment where the CPO management .?ystem 580O provide.s an 

agency feature that permits the CPO management system 3800 to accept or reject a 
given CPO on behalf of certain agency-based interexchange carriers S820 who have 
delegated such authority to the CPO manageinent system 5800. the CPO management 
central setter 6000 preferably includes a CPO nilcs database (not shown) for storing the 

2S CPO rules. The CPO rules may be stored in a secure database to maintain the integrity 
and confidentiality of sensitive information included in each CPO rule. 

In addition, the data storage device 6030 includes a CPO management 
process 6S00, discussed further below in conjunction with Figures 6Sa and 6Sb, and an 
IVRU process 6600, discussed further below in conjunction with Figures 66a and 66b. 

30 Generally, the CPO management process 6500 receives each CPO from a calling party 
5810, provides die CPO to each appropriate interexchange carrier S820 and thereafter 
determines if the terms of the offer have been accepted by any intetexchange carrier 
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5820. The IVRU process 6600 is preferably invoked by the CPO management process 
6500 to receive the parameters of the CPO from the calling party 5810. 

The communications port 6040 connects the CPO management central 
server 6000 to the local switch operator S850 and interexchange carriers 5820-5824. 
S The communications port 6040 preferably includes multiple communication channels 
for simultaneously establishing a plurality of connections. 

DATABASES 

Figure 61 illustrates an exemplary customer database 6100 that 
preferably stores infoimaiion on each customer (calling party) of the CPO management- 

10 system 5800, including biographical information and an indication of the local 
telephone company serving each customer. The customer database 6100 maintains a 
plurality of records, such as records 6105-6125, each associated with a different 
customer. For each customer name listed in field 6140, ihc customer database 6100 
includes the cu.itomer's address in field 6145, the manner in which the customer is 

IS bound in field 6150, an indication of Ihe local telephone company .'ierving the customer 
in field 6155 and the customer's telephone number in field 6160. The telephone 
number stored in field 6160 may be utilized, for example, as a customer identirier to 
index a historical database (not shown) of previous transactions associated with the 
customer. 

20 As shown in field 6150. a given customer may be bound by u pre- 

existing written or electronic contract on Tile, which may, for example, authorize an 
accepting interexchange carrier SS20 to charge the calling party 58 10 for a given call on 
the calling party's telephone statement or by means of a charge to a credit card, or other 
general-purpose account. As discussed below, the calling pany 5810 may be billed for 

25 telephone calls completed in acconlance with the present invention by the CPO 
management system 5800 or the local switch operator 5850, on behalf of the accepting 
interexchange cairier 5820. or directly by the accepting interexchange earner 5820. in a 
conventional maimer. 

In an inplementaiion where a CPO obligates a catling party 5810 to 

30 achieve niinimum usage for a predefined lime period, for example, where a calling party 
5810 agrees to spend at least two hundred dollars ($200) over twelve (12) months to 
obtain a lower rale, the agreed upon terms can be-immediately charged to a credit card. 



116 



WO98/1C061 



PCr/US97/15492 



or charged on a monthly basis. In addition, the credit card may not be charged unless 
the calling party 58JO fails to meet the obligations of the CPO. For example, the calling 
party 5810 may be billed directly for calls as charges are incurred, and the icmalning 
balance may be charged to the credit card account at the end of die agreed term. In 
5 addition, a calling party 58 10 can be charged a penalty if the calling party 58 1 0 does not 
agree to complete the call after the CPO is accepted by an interexchange carrier 5820. 

Figui« 62 illustrates an exemplary carrier database 6200 which 
preferably stores Information on each carrier which is registered with the CPO 
management system 5800 to provide long distance telephone service to calling parties, 
10 including address informalion. The carrier database 6200 maintains a plurality of 
records, such as records 6205-6225, each associated with a different carrier. For each 
carrier name listed in field 6240, the carrier database 6200 includes address informalion 
in field 6245. In addition, in an embodiment where the CPO rales of a given carrier are 
stored in an encrypted formal, or otherwise wheic secure transmissioas are required, the 
15 cryptographic key of the associated carrier is preferably stored in field 6250 of the 
carrier database 6200. Finally, the carrier daubase 6200 preferably stores an indication 
in field 6255 of the percentage of CPOs which have been offered lo each carrier which 
have actually been accepted by each respective carrier. In this manner, the CPO 
management system 5800 can offer a particular CPO to carriers in a sequence that is 
20 ranked in accordance with the CPO aaeptancc rate. In alternate embodiments, the 
carrier database 6200 can incorporate fields to facilitate the processing of CPOs in 
accordance with sequences based on (i) priorities negotiated by each carrier, or (ii) the 
highest commission rates paid by the carriers to the CPO management system 5800. 

Figure 63 illustrates an exemplary rate database 6300 that preferably 
25 stores published rate information for each carrier identified in the carrier database 6200. 
The rate database 6300 maintains a plurality of records, such as iccords 6305-6325. 
each associated with a diffeient canier. For each cairier identified in field 6340. the 
rate database 6300 preferably includes the corresponding domestic rate and international 
rate in fields 6345 and 6350, respectively. 
30 Figure 64 illustrates an exemplary CPO database 6400 which preferably 

contains a lecord of each CPO being processed by the CPO management system 5800, 
including the terms of the CPO and the associated status. The CPO database 6400 
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maintains a plurality of records, such as records 6405-6425, each associated with a 
different CPO being processed by the system 5800. For each CPO identified by CPO 
number in field 6440, the CPO database 6400 includes the date the CPO was recdved in 
field 6445, an identification (ID) number for the customer associated with the CPO in 

5 field 6450 and an indication of the telephone number to be called in field 6455. The 
parameters of the calling party's CPO are stored in field 6460 of the CPO database 
6400. The CPO database 6400 preferably stores the price the calling party is willing to 
pay for the call in field 6470. Field 6465 indicates the accepting carrier, once accepted 
and field 6475 records the cun^nt status of the respective CPO. such as pending, 

10 accepted, rejected or expired. 

PROCESSES 

PkX discusiied above, the CPO tnanagemenl central server 6000 preferably 
executes a CPO management process 6S0Oi shown in Figures 6Sa and 63b, to receive 
each CPO from acalling party 5810. provide the CPO to each appropriate inicrexchunge 

15 canier 5820 and thereafter dctemnine if ihe terms of the offer have been accepted by any 
iiuerexchange carrier 5820. As illustrated in Figure ga, the CPO management process 
6500 begins the processes embodying the principles of the present invention during step 
6S0S, upon receipt of a call from a calling party 5810, for example, via a private branch 
exchange (PBX) switch of the CPO management system 5800. 

20 Theieafier. during step 65 10, the CPO management process 6500 will 

extract the automatic number identification (AND number associated with the incoming 
call. A new record is then created in the customer database 6 1 00 during step 6SIS using 
the extracted ANI number as the customer identifier recorded in field 6160. Thereafter, 
the rVRlI process 6600. discussed below in conjunction with Figures 66a and 66b. or 

2S another customer interface process. i$ preferably executed during step 6S25 to receive 
the parameters of the CPO from the calling pany 58 10. including the telephone number 
of the called party 5830, the maximum price, the manner in which the CPO will be 
bound and any time limitations and other applicable restrictions. The received 
parameters of Ihe CPO are then stored in the CPO database 6400 during step 6530, 

30 indexed by the customer identifier (AMI) and then provided to die appropriate caiiieis 
during step 6535 (Figure 6Sb). It is noted that the CPO management system S8C0 can 
filter the CPOs provided to each carrier, for example, by only providing the CPO to 
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carriers who can route a call between the calling party 58 10 and the desired called party 
S&30 or only providing the CPOs to carriers designated by (he calling party 58 1 0. It is 
' fiinher noted that the CPO management process GSOO preferably evaluates the CPO 
against the CPO rules provided by any agency-based carriers during step 6S30 as well. 
5 A response to the CPO is preferably received from each carrier during 

step 6540. A test is then performed during step 6545 to determine if the terms of the 
CPO have been accepted by a carrier. If it is determined during step 6545 that the terms 
of the CPO have not been accepted by a carrier, then the calling paity 5810 is preferably 
notified daring step 63SO that the CPO has been rejected. The status of the CPO in the 
10 CPO database 6400 is then changed to "rejected" during step 6553, before program 
control lenninates during step 6560. 

If, however, it is determined during step 6545 that the term.<i of the CPO 
have been accepted by a carrier, then the full customer recoid from the CPO database 
' 6400 Is pieferably provided to the accepting carrier during step 6570 for the carrier to 
15 complete the call in accordance with the terms specified by the CPO. It is noted thai the 
calling pany 5810 may be billed for the call by the CPO management system 5800 or 
the local switch operator 5830 on behalf of the accepting intcrexchangc carrier 5820. or 
directly by the accepting inteiexchange carrier 5820, in a conventional manner. The 
local switch operator 5850 typically receives a percentage of the total cost to complete 
20 the call. Finally, the status of the CPO in the CPO database 6400 is then changed lo 
"accepted" during step 6575, before program control terminates during step 6580. 

As indicated above, the CPO nnanagement process 6500 preferably 
executes the IVRU process 6600, shown in Figures 66a and 66b, during step 6525 to 
receive the parameters of the CPO from the calling party 5810. including the telephone 
33 number of the called pany S830, the maximum price, and any time limitations and other 
applicable restrictions. As shown in Figure 66a, the IVRU process 6600 begins the 
processes embodying the principles of (he present invention during step 6610 by 
prompting the calling patty 5810 for the telephone nuifiber of (he called pany 5830. 
Thereafter, the interactive voice response unit (IVRU) captures the response of the 
30 calling party 5810 during step 6620 and provides the number (o be called to. the CPU 
6005. 
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The rVRU then prompts the calling pany 5810 for the price the calling 
party 5810 wishes to pay for the call and the manner in which the CPO will be bound, 
such as a charge to a credit card account, during step 6630, and captures the response 
during step 6640 providing the maximum price for the call to the CPU 6005. 

S Thereafter, the IVRU prompts the calling pany 5810 for any other restrictions or 
specifications associated with the CPO during step 66S0, including, for example, a time 
limit for the call, one or more desired carriers, if any, and a time limit for how long ihc 
CPO should be pending. The IVRU then captutes the response of the calling pany 5810 
during step 6660 and provides the additional restrictions or specifications to the CPU 

10 6005. Finally, the IVRU process 6600 instructs the calling party 5810 to hang up and 
wait for a response during step 6670 (Figure 66b), before program control terminates 
during step 6680. 

In this manner, the restrictions of the CPO are received by the CPO 
management system 5800 and then provided to each appropriate interexchange carrier 

IS 5820. If accepted, the interexchange carrier 5820 will complete the call between the 
calling party 58 10 and the desired called party 5830. in accordance wiih the terms of the 
CPO, and the calling pany 5810 is obligated to pay the accepting interexchange currier 
5820 for the cost of the call. 

In the embodiment shown in Figure S8A. a calling pony 58 10 desiring to 

20 place a call to a called party 5830 picks up the telephone set 5900 and dials a telephone 
number associated with the CPO management system 5800. The call is preferably 
received by a PBX switch or a related call processor. The telephone number of the 
calling party 5810 is then extracted from the call information, and used to access or 
create a record in the customer database 6I0O. The calling party 5810 is then connected 

25 to either an FVRU ora live operator to submit the terms of the calling party's CPO, such 
as the number to be called and the maximum cost. The caller then is preferably 
instructed to hang up and wait for a response. 

Once the CPO is received and processed by the CPO mahagemeni 
system 5800, it is then provided to a plurality of carriers. Each carrier 5820-5824 then 

30 determines whether to accept or reject the CPO. for example, based on one or more 
rules based on network capacity balancing. If the CPO is accepted, the CPO 
management system 5800 or the accepting carrier S820 notifies the buyer and places the 
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• call over the network of the accepting carrier, if 
there Is a time limit or other restrictions associated 
with the call, the calling party S810 is preferably 
notified at the time the call is initially established. 
The calling party 5810 may be billed for the call, for 
S example, by the CPO management system 5800, the 
accepting carrier 582D, or by the local telephone 
coo^jany operating the local switch 5850. In this 
manner, the call may be individually charged to a 
general purpose account, such as a credit card, or may 

10 be paid for by means of the calling party's 
conventional telephone bill. 

Similarly, the embodiment shown in Figure 
S8B, a calling party 5810 desiring to svibmit a CPO for 
telephone service for a predefined period of time, may 

15 contact the CPO management system 5800 using a 

subscriber terminal 5615. The CPO can specify, for 
example, the rate at which the subscriber is willing to 
pay for the telephone service and the length of the 
contractual obligation, as well as any flexibilities or 

20 restrictions that the calling party is willing to 
adhere to, in return for a discounted rate, such as 
calling during off-peak hours or a minimum spending 
obligation. 

Once the CPO is received and processed by the 

25 CPO management system 5800, the CPO is then provided to 
a plurality of carriers. Bach carrier 5620-5824 then 
determines whether to accept or reject the CPO. If the 
CPO is accepted, the CPO management syccem 5800 or the 
accepting carrier 5820 notifies the buyer and switches 

30 the long distance provider for the calling party to the 
acc^ting carrier 5820, in an appropriate manner. 

CPO MAIOGEMEIIT SYSTEM FOR EVENT TICKETS 
Another embodiment of the present invention 
will now be discussed with reference to Figures 67 
through 73g. The eokbodiment shown in Figures 57 
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• greater detail with reference to Figures 7ia through 
71e, respectively. 

Figure 71a illustrates an exemplary event 
table 7100 that preferably stores information on events 
for which tickets may be resold using the system of 

S Figure 67, including location and scheduling 

information. Event table 7100 maintains a plurality of 
records, such as record 7114, each associated with a 
different event. For each event identifier listed in 
event ID field 7102, event table 7100 includes an event 

0 type code stored in field 7104 and an event description 
stored in field 7106. The event type code stored in 
field 7104 represents the format of the event, for 
instance, a National Hockey League game is denoted as 
'NHL." The event description stored in field 7106 

5 describes the specific event. 

Event table 710 0 also preferably includes a 
venue ID stored in field 7106. The venue ID stored in 
field 7106 may be utilized, for example, -to index venue 
table 7120, more fully described with reference to 

0 Figure 71b. As shovm in Figiire 71a, each record stored 
in event table 7100 further includes a date stored in 
field 7110 and a time stored in field 7112. The date 
amd time of fields 7110 and 7112, respectively, 
represent the starting time of the event: associated 

15 with the record. The information stored in this table 
may be supplied to the central controller 6B00 from any 
number of sources, including promoters, venues and 
potential buyers and sellers. 

Figure 7'lb illustrates an exemplary venue 

10 table 7120. Each record of venue table 7120, such as 
record 7128, preferidsly stores data associated with and 
describing a venue. Venue table 7120 is preferably 
' indexed by field 7122 trtiich stores a unique venue 
identifier. Venue t«d>le 7120 further stores a theater, 
auditorium or stadium name in field 7124 and an address 
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• in field 7i26. 

Figure 71c illustrates an exemplary customer 
table 7130 which prefereOsly stores information on each 
customer registered with the electronic ticket sales 
system. Customer database 7X30 maintains a plurality 
S of records, such as records 7146 and 7148, each 
associated with a different customer. Customers 
registered in customer table 7130 may buy tickets, sell 
tickets or both buy and sell tickets , Customer table 
7130 Stores a unique cuetomer identifier for each 

10 customer in field 7132 and name and address information 
in fields 7134 and 7136. Preferably, the data 
maintained in customer table 7130 is provided by the 
customer during a registration process, at which time 
the customer is assigned a unique customer identifier. 

15 Customer table 7130 further stores customer 

credit card data. The customer's credit card number is 
stored in field 713B. The expiration date of the 
customer's credit card is stored in field 7140, and the 
name of the cardholder as it appears on the credit card 

20 is stored in field 7142. 

Figure 7ld illustrates an exemplary offer 
table 71S0 that preferably stores information relating 
to offers posted using the ticket sales system of the 
present embodiment. Offer table 7150 maintains a 

25 plurality of records, sueh as records 7170 and 7X72, 
each associated with an offer to buy or sell tickets. 
Each record of offer table 7150 Includes a unique offer 
identifier stored in field 715X that is assigned by 
central controller 6800 when the offer is posted. Each 

30 record of offer table 7150 includes fields for 

identifying the customer making the offer, conditions 
of the offer, the customer accepting the offer, aad 
• administrative information related to the offer . 

The customer identifier of the customer 
extending the. offer is stored in field 7152. 
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• Information relating to the cuscomer extending the 
offer may be easily obtained using the customer 
identifier of field 7152 as an index into customer 
table 7130. Each record in offer table 7150 further 
stores an event identifier in field 7153. The event 
S identifier indicates the event Co which the offered 
ticket (s) relate. Information regarding the event may 
be easily obtained using the event identifier of field 
73.S3 as an index into event: table 7100 . 

Each record of offer table 7150 further 

10 includes fields 7154 and 7155 that store the date the 
offer was made and the last day on which the offer may 
be accepted, respectively. Data indicating an offer 
type and offer status are also stored in each record of 
offer table 7150 ia fields 7156 and 7157. Field 7156 

15 scores a code indicating whether the offer is an offer 
to buy or an offer to sell one or more tickets. Field 
7157 stores a code indicating the status of the offer. 
Offer status possibilities include: pending, active, 
expired and fulfilled. 

20 Field 7158 of each record in the offer table 

' stores the number of seats to which the offer applies. 
Data identifying the location of seats related to the 
offer populate fields 7159-7164. In the event an offer 
requires a range of seat locations, data stored in 

25 fields 7159-7161 are used to identify the first seat in 
a range, and data scored in fields 7162-7164 are used 
to identify the last seat in a range. Field 716S 
stores the price per seat . 

In addition, each record of offer CoU>le 7150 

30 includes admisistracive data in fields 7166-7169. Data 
stored in field 7166 stores an amount of credit 
authorized to support Che offer. Once an offer has 
' been accepted, field 7167 scores a transaction 
idencifier chaC may be used as an index into 
CransacCion Cable 71B0, discussed more compleCely wich 
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• reference to Figure 7ie. Each record of offer table 
7150 optionally stores a pointer to a related, or 
linked, offer record. The pointer is stored in field 
7168 and represents the offer identifier of the next 
related record in offer table 7150. Finally, field 
5 7169 of each record of offer table 7150 stores one or 
more serial numbers of the original tickets that a 
seller would like to sell. 

Once an offer is accepted, central controller 
6800 adds a transaction record to transaction table 

10 7180. Figure 7ie illustrates an exemplary transaction 
tidsle 71B0 that preferably stores information relating 
to each accepted offer. Each accepted offer is 
assigned a unique transaction identifier that is stored 
in field 7181 of transaction table 7180 and field 7167 

15 of offer table 7150. An offer identifier of an 

associated record in offer table 7150 is stored in 
field 7182. This offer identifier nay be used as an 
index into offer table 7150 to retrieve information 
regarding the offer associated with a transaction 

20 record. 

Bach record of transaction table 7180 
preferably further includes field 7183 which stores the 
date the associated offer was accepted and field 7184 
'irtiich stores the total value of the transaction. Field 

25 7185 stores the amount charged to the buyer's credit 
card; field 7186 stores the amount of the seller's 
credit line reserved to support the acceptance; and 
field 7187 stores the fee charged for processing the 
transaction. Each record of transaction table 7180 

30' also stores a date in field 7188 indicating the date 
the ticket (s> are received by the operator of 
controller 6800. 

The customer identifier of the' seller is 
stored in field 7189, and data identifying the 
ticket (e) is stored in fields 7190 and 7194. Field 
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* 7190 stores the original ticket number (s) , and field 
7194 stores new ticket number (s). The new ticket 
numbers are assigned to distinguish original tickets 
from resold tickets and promote efficient resolution of 
potential conflicts between ticket holders. 
5 Optionally, central controller 6800 may 

include a contract detail table (not shown) containing 
form contract provisions which the central processor 
6BO0 retrieves and transmits to users at various times. 
For example, the contract table may include a contract 

10 provision that is transmitted to a buyer and 

incorporated into the guaranteed purchase offer. The 
contract table may also include a contract provision 
which is transmitted to a seller prior to requesting an 
acknowledgment of his intent to bind a buyer's offer 

15 and create a legally binding contract . These form 

provisions effectively fill the gaps between conditions 
specified by the buyer, specifying the generic contract 
details common to most contracts of this nature. 

Referring now to Figure 69, remote user 

20 terminal 6900 will now be described in greater detail. 
Remote user terminal 6900 can be a personal computer, 
Bcreenphone, stand alone kiosk, or any other device 
through which a customer can access the central 
controller 6B0O. Remote user terminal 6900 generally 

25 includes a central processing unit ("CPO") 6905 that 
controls the operation of remote user terminal 6900. 
CPO 6905 is electronically connected to a random access 
memory ("RAM") 6915, a read only memory ("ROM") 6920, 
an input/output port 6925, a clock 6935, a 

30 communication port 6940 and a data storage device 6960. 
CETJ 6905 receives inputs from a remote user with the 
ii^ut/output port 6925 and an input device 6945, such 
■ as a keyboud. CPU 6905° transmits outputs to a remote 
user via the Input/output port £925 and a video monitor 
6930. Further, the commanicatlon port 6940 provides 
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• the comraunication path to network 6845- Finally, the 
data storage device 6960 is a memory device containing 
central controller interface software 6955. 

Referring now to figure 70, venue controller 
7000 will now be described in greater detail. Venue 
5 controller 7000 generally includes a central processing 
unit ("CPU") 7010 that controls the operation of venue 
controller 7000 . The CPU 7010 is electronically 
connected to a random access memory ("RAM") 7020, 'a 
read only memory ("ROM") 7030, a clock 7040, a 

10 communication port 7050 that provides a comraunication 
path to central controller 6800, and a data storage 
device 7060. Data storage device 7060 is a persistent 
memory device containing a ticket table 7210 and a 
replacement ticket table 7230. Venue controller 7000 

15 further includes input device 7080 for receiving input 
data and output device 7070 for presenting or 
.displaying information to an operator. 

Figure 72a illustrates, an exemplary ticket 
table 7210 that preferably stores information about 

20 tickets issued for various seats at a particular venue. 
Bach ticket has a specific ticket number assigned to it 
by venue controller 7000 prior to issuance. Each 
record of ticket table 7210 preferably includes field 
7211 that identifies the event for which the ticket is 

25 valid, field 7212 that identifies the number assigned 
to each ticket issued for an event, and fields 7214- 
7220 that represent the location of the seat in the 
auditorium (i.e. the section, row and seat, 
respectively) . Ticket table 7210 could also contain 

30 fields representing other information specific to a 
venue, an event, or a seat. 

Figure 72b illustrates an exemplary 
replacement ticket table 7230 that pref eirably stores 
data relating to original ticket n-:£mberB that have been 
voided and assigned replacement ticket nunibers. 
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controller 6800 concacts the buyer's credit card issuer 
to ensure that the buyer has a valid credit card 
account and/or sufficient credit to pay for the 
requested tickets. The guaranteed purchase offer is 
then made available to potential sellers ^by posting the 
S offer using the web site linked to central controller 
6B00. Periodic maintenance is performed by central 
controller G800 to ensure that "active" offers have not 
expired. A potential seller can use the system of the 
present invention to browse offers and submit an 
10 electronic acceptance of a desirable offer. The 
acceptance by the potential seller is transmitted 
electronically to central controller 6800. Central 
controller 6600 proceases the acceptance and contacts 
the seller' s credit card issuer to ensure that there is 
IS ' sufficient credit to eevar a potential penalty for non- 
performance. This reservation of the seller's credit 
is intended to promote trust betmen the parties and, 
thereby, protect the transaction. After verifying 
available credit, both parties are notified of the 
20 binding transaction, and the tickets are electronically 
voided and assigned a replacement ticket number. The 
seller is then required to surrender the voided 
tickets. This may be accomplished by returning them to 
the venue, or the seller may mail the tickets to the 
2S operator of central controller 6800. Upon receiving 
the surrendered tickets, the operator of central 
controller 6800 directs payment to be transferred to 
the user selling the tickets. 

With reference to Figure 73a, a process by 
30 which a user logs on and begins using the system will 
now be described. As shown in step 7300, a user 
operating a remote terminal S900 establishes a 
connection with the central controller esoo through ' 
network 6845. The user may be either a potential buyer 
35 wishing to place a guaranteed purchase offer for 
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tickets, or a potential seller wishing to review offers 
for tickets. 

At step 7302, Central controller 6800 
requests a customer ID from the user. At step 7304, 
eentral controller 6S0O determines how to proceed based 
5 on whether or not the user already has a customer ID. 
If the user is registered with this service, and 
remembers his customer ID, he transmits his customer ID 
to central controller 6800 at step 7312, and the 
process continues with step 7314. 

10 If, on the other hand, the user is not 

registered with the service, or does not remetiftjer his 
customer ID, he must submit a negative response at step 
7304 and present relevant customer information to 
central -controller 6800, as shown by step 7306. At 

15 step 7308, central controller 6800 creates a record of 
the customer based on the received customer 
information. This information, including name, 
address, credit card and number, expiration date, and 
name as it appears on the credit card, is stored in 

20 customer table 7130. At step 7310, central controller 
6BO0 compares the information provided by the user with 
information already stored in customer table 7130. If 
a match is found, central controller 6600 retrieves the 
customer ID from field 7132 of customer table 7130. and 

25 transmits the customer ID number to the user. This 
service is provided for users who have given 
information previously, but do not remember their 
customer ID number. If no match is found, the central 
controller 6800 assigns a new customer ID to the user, 

30 stores it in field 7132 of customer table 7130, and 
transmits it to the user. 

At step 7314 the user indicates whether he 
would like to submit a guaranteed purchase offer, or 
review offers from potential buyers. The process steps 

35 relating to submitting offers are described more fully 
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" With reference to figures 73b-73c. The process steps 
relating to reviewing offers are described more fully 
with reference to figures 73d-73g. In an alternative 
embodiment, the user could also elect to advertise the 
availability of tickets for a certain event to 
5 potential buyers. Furthermore, a user could elect to 
review such advertisements, to get a better 
understanding of what a fair price might be, prior to 
submitting an offer. 

Figures 73b and 73c illustrate the process 

10 steps executed following the user's choice at step 7314 
to submit a guaranteed purchase offer. At step 7316, 
the central controller transmits general venue and 
event information to user terminal 6900 for display to 
the user. For instance, in one embodiment, central 

15 controller 6800 may provide a number of options to the 
user in order to pinpoint the specific event that the 
user would like to attend. The user could directly 
request a particular event, or proceed through a group 
of narrowing choices to ultimately find the right 

20 event. A user, for exainple, may be asked to identify 
any of the fields from event table 7100. Depending on 
the amount of information provided, the choice of 
events will be narrowed accordingly. For instance, if 
t^ie user provides only the event type (e.g. "NHL"), 

25 central controller 6800 scans the event table 7100 and 
provides all matches found in the event type field 
7104. This may be a long list of events, however, 
central controller 6800 may prompt the user for more 
information to narrow the list. The user may then 

30 select from the narrow list to find the event for which 
he is looking. For example, the user may specify only 
Saturday matinee performances of a particulcu: Broadway 
production in order to narrow the list. Central 
controller 6800 then provides the user with the correct 

35 event information, including the event ID from field 
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7102 of the event table 7100. The user includes this 
event ID as part o£ their guaranteed purchase offer so 
that it may be tracked by central controller in the 
offer table 7150. 

Next, at step 7318, the user selects the 
S desired event based on the event ID number. At step 
7320, central controller 6800 requests certain 
Information from the user pertaining to the offer, such 
as 

(1) the number of tickets desired; 
10 <2) the price for each ticket ; 

(3) the location desired for each ticket; 

and 

(4) optionally, a date through which the 
offer is valid. 

15 The user indicates the number of tickets he 

would like and the price he is willing to spend, based 
on the particular location of the tickets. The user 
nay choose the exact location at seats that correspond 
to the price he is willing to pay using a graphical 

20 representation of the venue. For instance, based on 
the venue ID nuinber (stored in field 7122 of venue 
table 7120) , central controller 6600 retrieves from 
memory and provides to the user at remote user terminal 
6900 a graphical representation of seating at that 

25 particular venue. In one embodiment, central 

- controller 6800 first provides a broad general outline 
of the entire venue (e.g. , display by sections) . The 
user can then click on a particular area to narrow his 
search for exact seats. With each successive selection 

30 click, the display screen at user terminal 6900 narrows 
the scope of displayed seating until the user finds the 
seats he desires. The user can then select the group 
of seats which corresponds to the purcliase offer. 
Central controller 6800 stores the selected seats in 

35 fields 7159-7164 of the offer table 7150. If the user 
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will consider both offers together during their review. 

Also, the user may link offers for two 
separate events as opposed to the same one. For 
example, instead of linking offers based on seat 
selection and price, the user may prefer to attend one 
5 of two events in the local area, but not both. Thus, 
he could link these offers so that potential sellers 
would be made aware that the offers were conditioned 
against an 'either/or' proposition. 

The central controller 6800 assigns an offer 

10 ID number to each offer in the offer ID field 7151, and 
assigns this number as the link ID number for linked 
offers, in link ID field 7168. Also, the offer date 
field 7154 is populated with a timestamp (e.g., date 
and time) indicating when the offer was posted. Next, 

15 central controller 6800 assigns the value "pending" to 
the status, field 7157. This value will change to 
'active' upon receipt of authorization from the user's 
credit card issuer. Further, central controller 6800 
calculates the authorized amount, and stores it in 

20 authorized amount field 7X66. The authorized amount 

field represents the amount of the user's credit which 
is reserved to "back up" the offer euid is usually equal 
to the total transaction amount . By reserving a 
portion of the user's credit, the ticket -seller and 

25 ticket service can be guaranteed that they will receive 
payment if the offer is accepted. In case of linked 
offers to buy, the authorized amount is the highest 
transaction amount of the linked offers. When a linked 
offer is accepted, the system automaticad.ly considers 

30 all related offers to be withdrawn. Finally, central 
controller 6800 stores all the information provided by 
the UBer> including the seat location based on the 
graphical representation of the venue, in the 
respective fields of the offer table 7150. 

3S At step 7330, the central controller 6800 
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" extracts legal contract language from the contract 
detail tablfe (not shovm) and transmits to the user at 
user terminal 6900. This language describes the legal 
implications of offering the guaranteed purchase offer, 
and the process is similar to reviewing terms before 
5 signing a written contract. If the user elects not to 
abide by these terms, he may cancel the offer. 
However, if the user does elect to abide by the terms, 
the user transmits a positive acknowledgment to central 
controller 6B00, and is legally bound to the terms of 

10 the guaranteed purchase offer. 

In Figure 73c, central controller 6B0O then 
contacts the user' s credit card issuer at step 7332 to 
receive authorization for the offer. First, central 
controller 6800 collects the user name, address, credit 

IS card type, credit card number, and expiration date from 
customer table 7130, based on the customer ID from the 
offer table 7150. This information along with the 
authorization amount from field 7166 of the offer table 
7150 is transmitted to the credit card issuer through 

20 credit card processor 6B30. 

At step 7334, the central controller 6600 
receives either an authorization or rejection from the 
credit card issuer through credit card processor 6830. 
The credit card issuer may reject the request for any 

25 niimber of reasons, including an expired card, 

overextended credit limit, or delinquency in payments. 
Open rejection, at step 733 6 central controller 6800 
notifies the user at user terminal 6900 of this 
rejection and requests separate credit card 

30 information. Alternatively, the user may trcuismit 
information corresponding to a separate credit card, 
which supplements or replaces his present information 
■ in the customer table 7130 . If alternative credit card 
information is provided, step 7332 is repeated in order 
to receive authorization for the charge. Upon 
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" receiving authorization from the credit card issuer 
through the credit card processor 6830, central 
controller 6800 updates o£fer table 7120, including 
changing status field 715.7 to "active" to confirm the 
posted offer. 

5 Figures 73d-73g illustrate the processing 

steps executed based on the user's choice at step 7314 
to review offers from potential buyers. At step 7340, 
central controller 6B0O transmits general venue and 
event information to user terminal S900 for display to 

10 the user. As discussed earlier at step 7316, central 
controller 6800 nay provide a number of options to the 
user to identify the exact event the user wishes to 
review. Ultimately, central controller 6600 provides 
the user with the event ID from field 7102 of the event 

X5 table 7100. At step 7342, the user supplies the event 
10 to central controller 6800 so it may Identify 
associated offers in offer table 7150. 

At step 7344, central controller 6800 
identifies offer records associated with the selected 

20 event ID and having an "active" status. Central 

controller 6800 transmits this data to user terminal 
6900 for display to the user. The user may review all 
offers for the specific event together, or. one at a 
Cime. In one embodiment, the user may review each 

25 individual offer through a graphic display of the 
venue, to pinpoint exactly where the buyer is 
requesting seats. In some cases, the offer may be for 
seats anywhere in the entire arena. In others, the 
offer may only be for a specific range of sections, 

30 rows or seats. In one embodiment, the user may be able 
to enter their exact ticket information to confirm 
whether it meets the requirements of the offer. 

- As previously discussed, linked offers will 
be appropriately identified upon presentation to the 
user. In this case, central controller 6800 allows 
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° associated linked offers to be reviewed simultaneously, 
ao that the user can compare the conditional offers 
submitted from a single buyer. 

Next, at step 734 6, central controller 6B00 
receives either a request to accept a particular offer, 
5 or a request to review offers for other events. In the 
latter case, steps 7340, 73 42 and 7346 will be 
repeated. It should be noted chat the user may exit 
the system at any time prior to accepting an offer. 

After the user transmits a request to accept 
a particular offer, at step 7348 the user transmits the 
original ticket number and seat location (i.e. section, 
row and seat) to central controller 6800. Upon 
receiving this information from the user, central 
controller 6800 at step 7350 transmits the original 
ticket number and seat location to the venue controller 
7000 for verification of the ticket's validity. 

Referring now to Figure 73e, at step 7352 
venue controller 7000 retrieves a record from ticket 
table 7210 matching the ticket number transmitted by 
central controller 6800 in step 73S0. Venue controller 
7000 verifies Chat the transmitted ticket number 
matches the transmitted seat location at steps 7354 and 
7356. If Che transmitted ticket and seat location do 
not match, at step 73SS, venue controller 7000 
transmits an invalid combination message to central 
controller eaoo. central controller 6800 then transmits 
a message to user terminal 6900 indicating that the 
ticket number and seat location are an invalid 
combination at step 7360. Upon receiving the invalid 
combination message at user terminal 6900, the user can 
resubmit the ticket and seat location to central 
controller 6800 at step 7370. The process then loops 
back to step 7350 . If the ticket number and seat 
location combination is valid, the process continues 
with step 7372. 
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" At Step 7372 of FigAire 73f, central 

controller 6800 transmits to user terminal 6900 legal 
contract language which Is displayed to the user 
selling his ticket. As previously indicated, this 
contract Isuiguage may be stored in a contract detail 
5 table (not shown) . This language describes the legal 
implications of accepting the guaranteed purchase 
offer, and the process is similar to reviewing terms 
before signing a written contract.. If the user selling 
his ticket elects not to abide by these terms, the user 

10 nay cancel bis acceptance. However, if the user elects 
to abide by the terms, the user transmits a positive 
acknowledgment to central controller 6600, and is 
legally bound to the acceptance. 

Central controller 6800 then contacts the 

15 user's credit card issuer at step 7376 to receive 

authorization for the acceptance. Central controller 
6600 requests authorization from the credit card issuer 
to reserve a portion of the user' s credit based on the 
offer information and credit information collected from 

20 the user at step 7306 and stored in customer table 

7130. This credit reservation is a fraud deterrent and 
may be used as a penalty in the event the seller fails 
to deliver the tickets. Such a penalty creates buyer 
confidence and provides assurance -to a user buying the 

25 ticket that the user selling the ticket will, in fact, 
relinquish the tickets. The penalty could be paid to 
the user buying the ticket if the user selling the 
ticket attempts to repudiate the agreement. This 
penalty nay be determined in a number of ways including 

30 imposing a flat penalty on the user selling the ticket 
or in^osing a penalty equal to the entire amount 
offered by the user buying the ticket. 

At step 7374, central controller -6800 
collects information from the user selling the ticket . 
The information may include the user name, address, 
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* credit card number and expiration date froth customer 
table 7130, based on the customer ID retrieved from the 
offer table 7150. This information, along with the 
authorization amount from field 7166 of the offer table 
7150, is transmitted to the credit card issuer through 
S credit card processor 6830 . 

At step 7376, central controller 6800 
receives either an authorization or rejection from the 
credit card issuer thrpugh credit card processor 6830. 
The credit card issuer may reject the request for any 
10 number of reasons, including an expired card, 

overextended credit limit, or delinquency in payments. 
Upon rejection, at step 732B central controller 6B00 
notifies the user at user terminal 6900 of the 
rejection and requests alternate credit card 
15 information. The user may attempt to transmit the same 
credit information as provided earlier, because the 
user may have mistakenly transmitted incorrect 
information earlier. Alternatively, the user may 
transmit information corresponding to an alternate 
20 credit card, which will supplement or replace the 
credit card information in customer taible 7130. 
Further, the user could cancel the transaction 
altogether. If alternative credit card information is 
provided, step 7374 is repeated In order to receive 
25 authorization for the charge. 

If central controller 6800 receives 
authorization from the credit card issuer through 
credit card processor 6830, the process continues with 
step 7380 wherein central controller 6800 generates and 
30 assigns a transaction ID to the sale. This transaction 
ID is stored in field 7167 of the offer table 7150. 
Further, central controller 6800 creates a new record 
in transaction table 7180, indexed by the assigned 
transaction ID. The assigned transaction ID is also 
stored in field 7181 of transaction table 7180. The 
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original ticket number 7190 field of transaction table 
7180 is populated with the appropriate ticket number (s) 
from the user selling the ticket. Further, central 
controller 6800 timestanips the acceptance using date 
field 71B3 indicating when the acceptance was posted. 

5 Once the guaranteed purchase offer has been 

accepted, central controller 6800 uses the customer ID 
from field 7152 as an index into customer table 7130 to 
retrieve the name of the user buying the ticket . At 
step 7382, central controller 6800 transmits the name 

0 of user buying the ticket to the venue controller 7000. 

At step 7384. venue controller 7000 creates a 
new record in replacement ticket table 7230. The new 
record is populated with information indicating the 
buyer's name, the original ticket number, the section, 

S row and seat of the ticket. As shown at step 7386, the 
new record is further populated with a replacement 
ticket number assigned by venue controller 7000 . The 
replacement ticket number is then transmitted to 
central controller 6800. 

0 Once central controller 6BO0 has received the 

replacement ticket number 7242 from venue controller 
7000, central controller 6800 then updates the new 
ticket number, field 7194 of transaction table 7180 at 
step 7388. At step 7390, central controller 6800 

13 determines the payment due and charges the credit card, 
of the user buying the ticket, the price of the ticket 
plus a processing fee 7187. Central controller 6800 
also updates field 7185 of the transaction tcible 7180 
with the amount charged. Finally, central controller 

10 6800 updates field 7189 with the seller ID of the user 
accepting the offer, and central controller 6600 
updates field 7186 with the seller amount authorized in 
• the event that the seller tries to use his sold ticket. 
Field 7184 is updated based on buyer amount charged 
7185 less the processing fee 7187. Although fees of 
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* the present embodiment are illustrated as being stored 
in a table, such 'fees could easily be calculated 
instead of being retrieved from a table. 

At step 7392, central controller 6800 
transmits a message to user tensinal 6900 to notify the 
5 user selling the ticket that it will credit his credit 
card account with the sale amount of the ticket as soon 
as central controller 6800 receives verification that 
bhe original tickets have been surrendered. 

At step 7394 the central controller transmits 

10 replacement ticket number 7292 and a message to the 
user buying the ticket indicating that his guaranteed 
offer has been accepted. The user buying the ticket 
may then print the replacement ticket number, take it 
to the venue and use it to gain access to the desired 

15 event, at step 7396 . The cancellation of the original 
number and issuance of a replacement ticket number tied 
to the purchasing user's name is done in order to 
prevent fraud hy either the ticket seller and/or the 
purchaser . 

20 For instance, if a seller arrives at a venue 

with a ticket, and a purchaser also arrives to the same 
venue with a replacement ticket for the same seat, the 
venue controller can be accessed to determine which 
ticket ±8 valid. The replacement ticket always 
. 25 supersedes the original ticket, provided it is 

registered in the replacement ticket table 7230 o£ the 
venue controller 7000. If such fraud is attempted by 
the seller and detected by central controller 6800, the 
central controller can charge the seller's credit card 

30 account the seller amount authorized in field 856 of 
transaction table 7160. 

As another example, if two people arrive at 
- the venue with the same replacement ticket, the venue 
controller can be accessed to determine the rightful 
owner, based on the contents of the new buyer name 

142 

SUBSTITUTE SHEET (RUt£ 26) 



wo9ano3<i 



FCnnS97/IS4tt 



• field 7240, of replacement ticket table 7230. These 

measures taken against fraud will assure customers that 
there will be no problems in using central controller 
6800 to buy and sell tickets. 

Finally, at step 7398, central controller 
5 G800 receives verification that the original ticket has 
been received from the seller, and credits the credit 
card account of the user selling the ticket with the 
transaction amount 7184 . Central controller further 
updates the date tickets received field 718B 

10 accordingly. Surrender of the ticket is preferably 
accomplished by delivery of the ticket to a will call 
window of the venue, however other surrender 
arrangements are possible, such as through the postal 
service or Federal Express. Once the ticket has been 

15 surrendered and the transaction is complete, central 

controller 6800 updates status field 7157 of the offer 
table 7150 to "con^leted" for cracking purposes. Upon 
receipt d£ the surrendered tickets, central controller 
6800 credits the account of the user selling the 

20 tickets . 

Although the preferred method of surrendering 
the original tickets is using the mail or other 
delivery mechsmisn, numerous alternate embodiments . are 
possible. Using one alternate embodiment, ticket 

25 reden^tion could be constructively accomplished at the 
tine an offer to buy is irrevocably accepted. The 
alternate embodiment en^loys event tickets that can be 
physically altered to render them invalid or void. 
Bach ticket includes a unique ticket number that is 

30 pre-printed on the face of the ticket, but obscured 

from view by a scratch-off covering, such as an opaque 
latex coating. The ticket number is unknown to the 
' ticket holder unless the scratch-off covering is 
removed. 

At the time of acceptance, the seller 
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° possessing the tickets is instructed to remove the 
covering over the ticket number on each ticket to be 
sold. The ticket number is provided co central 
controller 6800 to verify tliat Che ticket seller is, in 
fact, in possession of valid tickets. The ticket 

5 number provided for each ticket involved in the 
transaction is then electronically voided and 
replacement ticket n\unber is assigned as previously 
described. 

The act of revealing the ticket number not 

10 only serves to verify the ticket seller's possession of 
the tickets, but also eliminates the need for the 
seller to surrender the tickets because removal of the 
scratch-off covering voids the tickets. While this 
alternate embodiment requires additional structure with 

15 respect to the event tickets, it eliminates the need to 
reserve a portion of the seller's credit line as a 
penalty for falling to return the unused tickets. 

An illustrative example of the invention will 
now be described using the data populating various 

20 fields of the figures. Record 7172 of the offer table 
7150 is a guaranteed offer to buy as indicated by type 
field 7156 that has been submitted by user 4000 as 
identified by customer ID field 7152. User 4000, as 
denoted by record 7148 in the customer table 7130 is 

25 Sue Black, residing at 101 Pink Ave in Norwalk, CT. 

The credit card number submitted to central controller 
6800 is Discover card number 4444-4444-4444-4444 that 
expires 9/02 and was issued to Susan Black. 

In record 7172 of the offer table 7iS0, Sue 

30 Black has posted a guaranteed offer to buy two tickets 
to event ID EOOl, as denoted by event ID field 7153, 
for $200.00 per ticket in the first row of the first 
■section of the venue. As denoted "by record 7114 of 
event table 7100, event EOOl is an NHL game, 
specif iccQly NJ Devils vs. Hew York Rangers, occurring 
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° store information relating to the original tickets 
issued to Jill Janson. Records 7244 and 7246 of 
replacement ticket table 7230 store the replacement 
ticket numbers issued by central controller 6800 to Sue 
Black, which replace the original ticket numbers given 
5 to Jill Janson. These records are stored by venue 
controller 7000 to be used in the event of fraud as 
previously described. 

It is iiportant to note that in the 
embodiment described above, "the notification of the 

10 parties, both buyer and seller is performed through 

contacting their respective remote user terminals. This 
notification can also be performed using conventional 
technology including but not limited to telephone, 
facsimile, e-mail and paging. 

IS In addition to the guaranteed offer and 

acceptance system of the present invention, the present 
embodiment is also well suited for other eispects of 
ticket resale. For exanple, the present embodiment can 
include a registration process for certain events or 

20 tickets. Such a process would enable a prospective 
ticket buyer to set up a| ticket watch which could be 
inqslemented by central controller 6800. Central 
controller 6B0O could periodically poll offers to 
determine if specific tickets are available. 

25 Availability could be transmitted to a user via 

conventional telephone lines. E-mail, facsimile or 
pager. A notification preference could be determined 
^by the user during the registration process. 

Another aspect of ticket resale that is well 

30 suited to the present embodiment is advertising. 

Instead of simply allowing users to place, review and 
accept offers, the system could provide advertising for 
- products related to events and tickets . 

CPO AMD TBOar PA&IY INPUT lOUIAaEHBNT SYSTBH 
The method and apparatus of another 
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embodiment of the present invention, which allows 
sellers to evaluate the acceptability of an o£fer from 
a buyer in light of information relevant to the offer 
from a third party, will now be discussed with 
reference' to Figures 74 through 82 . Although the 
description which follows in conjunction with Figures 
74 through 82 employs a finMce- related embodiment for 
purposes of illustration, those skilled in the art will 
understand that the scope of the present invention is 
not limited thereto. Accordingly, in the description 
below, sellers and buyers may be referred to as lenders 
and borrowers, respectively. 

Referring to Figure 74, a system 7410 for 
processing the sale of products comprises a central 
controller 7412 which communicates with a Isorrower 
terminal 7414, third parties 7416 and 7418, and lender 
terminals 7420, 7422 and 7424 via the Internet or other 
suitable connnunication network. The illustrated 
numbers of borrower terminals, third parties and/or 
lender terminals are illustrative, not limiting. It 
will be understood by those skilled in the art that any 
number of borrower terminals, third parties and/or 
lender terminals may cotmmmicate with the central 
controller 7412 in alternate embodiments of the present 
invention. 

The borrower terminal 7414 is typically a 
computer or other apparatus for generating and 
transmitting signals to the central controller 7412. 
Ideally, the borrower terminal is a conventional 
personal conqputer, such as one based on an Intel 60386 
microprocessor, that is connected to a modem or other 
remote communication device. A customer desiring to 
purchase a product (good or service) operates the 
' borrower terminal 7414 to transmit an offer signal 
including at least one condition signal to the central 
controller 7412. The offer signal defines a 
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" conditional purchase offer having at least one 
condition from the customer. 

In the present embodiment, the customer is a 
"borrower" who desires to obtain a loan (i.e., he 
desires to "purchase" a loan) , Accordingly, the offer 

S signal defines an offer to obtain a loan. As described 
in detail below, the offer may comprise any of a 
variety of conditions, and so the offer signal 
comprises one or more condition signals specifying the 
borrower's desired conditions. For example, the 

D borrower may desire a particular monthly payment amount 
for the loan and/or a particular interest rate. 

The borrower terminal 7414 also transmits to 
the central controller 7412 a payment identifier signal 
for specifying a general -purpose account from which 

5 funds may be paid. The payment identifier signal 
specifies, for example, a credit card number or 
checking account number of an account owned by the 
borrower . 

The payment identifier signal is used to 
0 effectively "bind" the borrower by identifying funds to 
be paid if the borrower fails to carry out (consummate) 
his offer to purchase . The payment identifier thereby 
assures potential lenders that the offer is genuine and 
binding. For example, if the borrower reneges, the 
S payment identifier may be used to collect an amount of 
funds sufficient to offset the lender's costs in 
processing the borrower's offer. The specific amount 
of funds to collect can be either set by the central 
controller 7412, or may be left to the discretion of 
0 the lender. 

In other embodiments, the payment identifier 
may additionally be used to collect other fees, even if 
•the borrower consummates his- offer. For example, the 
payment Identifier may be used to collect loan 
transaction fees or even monthly loan payments. 
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" If a leader operates a lender terminal to 

accept the offer, thereby incurring costs processing' 
the offer, the lender is assured that he (i) may sell 
the loan to the borrower if he can satisfy the loan 
conditions; or (ii) if the borrower fails to abide by 
5 the terms of the offer (e.g. , the borrower fails to 
consummate the loan) , the lender collects a penalty 
payment paid from the account specified by the payment 
identifier signal. In both cases, the lender is 
assured that acceptance of the offer will yield funds, 

10 and thus acceptance of the offer is not as risky as in 
other systems for processing the sale of products. 

As described above, sellers often require 
information relevant to the offer from a third party in 
order to determine whether to accept the offer. For 

15 example, the offer signal from the borrower would not 
be evaluated and accepted by a lender unless the lender 
knew the borrower's credit history or credit score. 
Accordingly, the Bystem 7410 includes third parties 
7416 and 7418 for providing the central controller 7412 

20 with informational signals. The informational signals 
desirably define any information that (i) should not be 
viewed and/or altered by the buyer, and/or (ii) is 
necessary to determine the validity and/or value of the 
offer. The third parties 7416 and 7418 may be, for 

25 exain>le, a credit-reporting bureau, which provides the 
central controller 7412 with credit information alsout 
the borrower, and an appraiser for appraising the value 
of loan collateral submitted lay the borrower. 

The central controller 7412 receives and 

30 stores the transmitted offer signal, payment identifier 
signal and informational signal. As described in 
detail below, the signals are stored in several 
• databases, thereby facilitating the searching for and 
retrieval of data represented In the databases. The 
central controller 7412 uses 'the stored signals to 
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allow any of the lender terminals 7420, 7422 and 7424 
to accept the offer, if the offer is eoasidered 
adequate . 

If a lender terminal accepts the offer, the 
borrower is bound to abide by the terms of the offer. 
5 If the borrower does not, for example if the borrower 
does not sign the necessary loan paperwork, the central 
controller 7412 initiates the use of the payment 
identifier signal to collect the funds. For example, 
the central controller 7412 may transmit the payment 

10 identifier signal to the lender terminal, thereby 
allowing the lender to collect the funds. 
Alternatively, the central controller 7412 may itself 
use the payment identifier signal to collect the funds. 
The central controller 7412 may manage the 

15 acceptance of offers in various ways. In embodiments 
described below, accepting an offer can ipclude (i) 
transmitting the offer signal to leader teminals, eutd 
in turn receiving acceptance signals from lender 
terminals, or (ii) comparing the offer signal with 

20 seller's rules, and determining whether the offer 
satisfies any of the rules. 

Figure 75a illustrates a central controller 
753.0, which is an embodiment of the central controller 
7412 (Figure 74) that is used when accepting an offer 

25 includes the step of receiving acceptance signals from 
lender terminals. The central controller 7530 includes 
a central processing unit 7S31, such as one or more 
conventional inicroproceBsors , and a storage device 
7532, such as a RAM, floppy disk, hard disk or 

30 combination thereof, which is connected to the central 
proeesaing unit 7531. The central proceoBing unit 7531 
and tha storage device 7532 may each be (i) located 
• entirely within a single ccsgqiuter; (ii) connected 
thereto by a reTBOte communication link, such as a 
serial port cable, telephone line or radio frequency 
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• transceiver ; or (iii) a combination thereof. For 
exampl^i the central controller 7530 may comprise one 
or more computers connected to a remote server conputer 
for maintaining databases. 

The storage device 7532 stores (i) a program 

5 7533 for controlling the central processing unit 7531 
in accordance with the present invention, and 
particularly in accordance with the processes described 
in detail hereinafter; (ii) a borrower database 7534 
for maintaining information on each borrower who 

B submits an offer; (iii) a lender database 7536 for 
maintaining information on each lender who may accept 
an offer; (iv) an offer database 753fl for specifying 
each offer submitted to the central controller; (v) a 
credit report database 754 0 for storing informational 

5 signals describing credit worthiness; (vi) a collateral 
database 7542 for storing informational signals 
describing collateral used in connection with the 
offers; and (vii) a response database 7544 for 
specifying each acceptance received by the central 

Q controller . 

The program 7533 also includes necessary 
program elements, such as "device drivers" for 
-interfacing with computer peripheral devices. 
Appropriate device drivers and otber necessary program 

5 elements are known to those skilled in the art, and 
need not be described in detail herein. Each of the 
databases 7534, 7536, 7538, 7540, 7542 and 7544 are 
described in detail below. 

Figure 75b illustrates a central controller 

B 7560, which is an embodiment of the central controller 
7412 (Figure 74) that is used when accepting an offer 
includes the step of determining whether the offer 
• satisfies any lender-specified rules. The central 
controller 7560 includes a central processing unit 7561 
and a storage device 75S2 connected to the central 
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processing unit 7561. The central processing unit 7561 
and the storage device 7562 may each be implemented in 
a manner similar to the central processing unit 7531 
and the storage device 7532 of Figure 75a. 

The storage device 7S62 likewise stores (i) a 
5 program 7533 for controlling the central processing 
unit 7B61 in accordance with the present invention; 

(ii) a borrower database 7534 for maintaining 
Information on each borrower who submits an offer; 

(iii) a lender database 7536; (iv) an offer database 
10 7536; Iv) a credit report database 7S40; and (vi) a 

collateral database 7542; and further stores (vii) a 
rules database 7564 for storing lender-specified rules 
for accepting offers. The program 7533 and the 
databases 7534, 7536, 7538, 7540 and 7542 function as 

IS described above, and the rules database 7564 is 
described in detail below. 

Referring to Figure 76, the borrower database 
7534 of Figures 7Sa and 75b stores exemplary records 
7S70 and 7672, each of which corresponds to a borrower 

20 who submits an offer. Each record stores an offer 
identifier 7674 that is generated by the central 
controller 7412 IFigure 74) and uniquely identifies an 
Offer made by the borrower. Bach record also stores 
the name 7676, address 7678 and telephone number 7fiS0 

25 of the borrower. 

Referring to Figure 77, the lender database 
7536 of Figures 75a and 7Sb stores exemplary records 
7790 and 7792, each of which corresponds to a lender 
who may accept an offer. Bach record stores a lender 

30 identifier 7794 that is generated by the central 

controller 7412 (Figure 74 > and uniquely identifies a 
lender, as well as the name 7796, address 7798 and 
' telephone number 7800 of the lender. 

Referring to Figure 78, the offer database 
753B .of Figiires 7Sa and 75b stores exeiq>lary records 
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• 7810, 7812 and 7814, each of which corresponds to a 

received offer. Each record stores an offer identifier 
7B16 that (i) uniquely identifies an offer, and (ii) 
corresponds to one of the offer identifiers 7674 of the 
borrower database 7534 of Picfure 76. Each record 
5 further stores the date 7818 and time 7820 at which the 
offer was received, and conditions of the offer, such 
as a loan amount 7822, a monthly payment 7824, a loan 
term 7826 and a loan interest rate 7828. Each record 
may also have an expiration date 7830 and expiration 
10 time 7832, after which the corresponding offer may not 
be accepted. A loan type 7834 may also be stored in 
embodiments where it is desirable for lenders to Jcnow, 
for example, whether the desired loan is secured. 

Referring to Figure 79, the credit report 
15 database 7540 of Figures 75a and 75b stores exemplary 
records 7942, 7944 and 7946, each of which corresponds 
to a received offer. Each record stores an offer 
identifier 7948 that (i) miquely identifies an offer, 
(ii) corresponds to one of the offer identifiers 7674 
of the borrower database 7534 of Figure 76. and (iii) 
corresponds to one of the offer identifiers 7816' iri the 
offer database 7S38 of Figure 78. For each offer, 
there is also stored a credit report identifier 7950 
that is generated by the central controller 7412 
(Pigiire 74) and uniquely identifies the results of a 
credit check or other evaluation of a borrower who 
submitted the corresponding offer . A credit score 7952 
defines the results of that evaluation. 

Referring to Figure 80. the collateral 
database 7542 of Figures 75a "and 75b stores exemplary 
records 8060. 8062, 8064 and 8066, each of which 
corresponds to a received offer. Each record stores an 
offer identifier 8068 that uniquely identifies an offer 
and corresponds to the offer identifiers described 
above. in connection with Figures 76, 78 and 79. For 
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' each offer, there is also stored the type 8070 of 

collatexal, a deBcription S072 of the collateral and a 
value B074 of the collateral. 

Referring to Figure >81a, the response 
database 7544 of Figure 75a stores exemplary records 
S 8180 and 8182, each Of which corresponds to a received 
response to an offer. Each record stores an offer 
Identifier 8184 that uniquely identifies an offer and 
corresponds to the offer identifiers described iUbove in 
connection with Figures 76, 78, 79 and 80. Each record 

10 also stores a response identifier 8166 that uniquely 
identifies each received response, a lender identity 
8188, and conditions of the loan that the lender is 
willing to provide, such as a loan amount 8190, a 
periodic payment amount 8192, a loan term 8194 and a 

IS loan interest rate B196. The time 819a and date 8200 
of the re^onse are also stored in the response 
database 7544. 

Referring to Figure 81b, the rule database 
7S64 of Figure 75b stores exenplary records 8212 and 

20 8314, each of which corresponds to a rule defining 

criteria for when a lender will accept an offer. Each 
record stores a rule identifier 8216 that uniquely 
identifies a rule, a lender identity 8218 identifying 
the lender who accepts offers satisfying the rule and 

25 inile restrictions 8220 which specify the criteria for 
accepting an offer. 

Figures 82a and a2b illustrate a method 8230 
for processing sales- of a loan between a borrower 
terminal and one or more lender terminals. The 

30 illustrated method 8230 is performed by the central 
controller 7530 Of the etnbodicient of Figure 75a, in 
which accepting an offer includes receiving acceptance 
• signals from lender terminals. The central controller 
receives from the borrower terminal an offer signal 
(step 8232) . As described above, the offer signsa 
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infomatlonal signal including credit information from 
a third party (step 8242) . The informational signal 
may further include other information relevant to the 
Offer, such as an appraisal value of collateral offered 
by the borrower. As described above, more than a 
single third party may supply desired anformational 
signals to the central controller. 

The central controller then transmits the 
offer signal and the informational signal (s) to one or 
more lender terminals (step 82441. The central 
controller in turn receives, from at least one of the 
lender terminals, one or more acceptance signals 
responsive to the transmitted offer signal and 
informational signal (step 8246) . One of the 
acceptance signals is selected (step 8246) , and the 
corresponding lender terminal is identified (step 
8250) . The borrower is thereby bound to the identified 
lender under the terms and conditions of the offer. If 
the borrower later reneges by not abiding by the terms 
of the offer (step 8252) , use of the payment identifier 
signal is initiaced in order to collect the funds (step 
B254) . For example, the central controller may collect 
the funds, or may transmit the payment identifier 
signal to the identified lender terminal, allowing the 
lender to directly collect the funds.. 

The step 8248 of selecting one acceptance 
signal may be performed in a nuiriser of ways. For 
example, the first received acceptance signal or a 
random one of the acceptance signals may be selected. 
In still another embodiment, the acceptance signals may 
be sorted according to a predetermined sort criteria, 
such as sorted by lowest interest rate or lowest 
monthly payment amount. Selecting the first of the 
■ sorted acceptance signals would then provide the lowest 
interest rate or monthly payment, respectively. A 
number of "tie-breaking" methods may be used to select 
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• one acceptance signal fxxMn a group of equally 
attractive acceiJtance signals. 

It may also be desirable' to allow the 
borrower to select the acceptance signal, and thus 
choose the lender. In such an embodiment, a plurality 

5 of lender signals is transmitted to the borrower. Each 
lender signal indicates a lender, which in turn 
corresponds to one of the plurality of acceptance 
signals. The borrower terminal then provides the 
central controller with a selection signal indicative 

0 of a selected lender signal. The selection signal 
thereby indicates a corresponding acceptance signal, 
which is selected. 

Selection of an acceptance signal may also 
occur through a condition specified by the offer. For 

5 example, an offer may comprise condition signals 

indicative of a loan amount, a periodic payment amount 
and a request for a lowest interest rate . Thus , the 
acceptance signal indicating the lowest interest rate 
received within a predetermined time is selected. 

0 Similarly, an offer may con^rise condition signals 
indicative of a loan amount, an interest rate and a 
.request for a lowest periodic payment amount. Such an 
. .offer may further conprise a condition signal 
.indicative of a maximum loan period. Accordingly, the 

5 acceptance signal indicating the lowest periodic 
. payment amount is selected. 

Figure 82c illustrates another embodiment of 
a method 8260 for processing sales of a loan between a 
borrower terminal and one or more lender terminals. 

0 The illustrated method 8260 is performed by the central 
controller 7560 of the emJoodiment of Figure 75b, in 
which accepting an offer includes con^aring the offer 
■signal with seller's rules, and determining whether the 
offer satisfies any of the rules. 

As described above in connection with 
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• Figures 82a and 82b, the central controller receives 
from the borrower terminal an offer signal (step 8262) , 
and also receives a payment identifier signal (step 
8264) . The central controller validates the payment 
identifier signal (step 8266). If t:he payment 
3 identifier is not valid, the borrower terminal is 
requested to retransmit the offer and payment 
identifier (step 8268) . The central controller also 
validates the received offer signal (step 8270) , 
thereby determining whether the received offer "signal 

10 meets predetermined validation criteria. If the offer 
is not meaningful, the borrower terminal is requested 
to retransmit the offer and payment identifier (step 
8268) . The central controller also requests and 
receives an informational signal including credit 

15 information from a third party (step 8272) . 

The central controller stores at least one 
rule signal from each of a plurality of sellers '(step 
8274) . Each rule signal Includes at least one seller- 
defined restriction. Some restrictions may involve 

20 offer conditions, while other restrictions may involve 
the informational signal . For example , a rule may 
include the restrictions that the loan amount must be 
less than $100,000 and the credit score must be greater 
than eighty. It will be understood by those 8)cilled in 

25 the art that the step 6274 of storing the rule signals 
may occur either before or after the offer signal is 
received. 

The offer signal and the informational signal 
are compared with at least one- rale signal (step 8276). 
30 If it is determined that ttie conditions of the offer 
and the informational signal satisfy each seller- 
defined restriction of any rule (step 8278), the 
corresponding lender is identified (step 8280) . If 
more than one rule is satisfied, one rule is selected 
in accordance with any of the methods described albove. 
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" The borrower is thereby bound to the identified lender 
under the terms and conditions of the offer. If the 
borrower later reneges by not abiding by the terms of 
the offer Istep 8282), use of the payment identifier 
signal is initiated in order to collect the f\mds (step 
5 8284), as described above. 

Those skilled in the art will recognize that 
the method and apparatus of the present invention has 
many applications, and that the present invention is 
not limited to the representative examples disclosed 
10 herein. Moreover, the scope of the present invention 
covers conventionally known variations and 
modifications to the system components described 
herein, as would be known by those skilled in the art. 

15 
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The claims defining the inventtoo are its follows; 

1. A computer device for consummating a binding contract between a remote 
prospective buyer and a remote potential seller, said computer device comprising: 

a memory device; and 

a processor disposed in communication with said memory device, said processor 
configured to receive from the remote prospective buyer (a) a binding purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a general 
purpose financial account from which iiinds may be paid for a purchase meeting said at 
least one condition; said processor further configured to transmit the purchase offer to a 
plurality of remote potential sellers, receive fix>m at least one of the remote potential 
sellers an unconditional acceptance of the offer, and transmit notification to the buyer that 
the binding purchase offer was accepted by a first-accepting seller without revealing the 
Identity of the seller. 

2. The computer device as claimed in claim 1, wherein said processor is further 
configured to initiate the use of the payment identifier to effect payment for the purchase 
from the buyer. 

3. The computer device as claimed in claim 1, wherein the general purpose 
financial account is a credit card account 

4. A computer device for consummating a binding contract between a remote 
prospective buyer and a remote potential seller, said computer device comprising: 

a memory device; and 

a processor disposed in communication with said memory device, said processor 
configured to receive from the remote pro^iective buyer (a) a binding purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a gmeral 
purpose financial account of an electronic settlement system from which funds may be 
paid for a purchase meeting said at least one condition; said processor fiuther configured 
to transmit the binding purchase ofSa to an electronic buying network of remote potential 
sellos, receive from at least one of the remote potential sellers an unconditional 
acceptance of the binding purchase offer, initiate the use of the payment identifier to 
render payment for said purchase by charging said goiml purpose financial account of 
said electronic settlement system and transmit notification to the buyer that the binding 
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purchase offer was accepted by a fiist-accepting seller without revealing the identity of 
the seller. 



5. The computer device as claimed in claim 4, wherein said electronic settlement 
5 system is a credit card system. 

6. The computer device as claimed in claim 4, wherein said electronic settlement 
system is separate irom said electronic buying network. 

10 7. The computer device as claimed in claitns 1 or 4, wherein the at least one 
condition is selected firom the gioup consisting of price, quantity, delivery date, quality, 
geographic location, and anonymity. 

S. The computer device as claimed in claim 1 or 4, wherein the processor is 
* 15 configured to notify at first-accepting seller that it has entered into a legally binding 
contract with the buyer. 

"I 9. The computer device as claimed in claim 1 or 4, wherein the notification to the 

buyer of acceptance identifies a first-accepting seller. 

20 

10. The computer device as claimed in claim 1 or 4, wherein the binding purchase 
offer includes an expiration date and is non-revocable prior to that dale, 

11. The computtt device as claimed in claim 1 or 4, wherein the binding purchase 
25 offer expires if it is not accepted vrithin a predetetmined time period. 

12. The coRQniter device as claimed in claim I or 4, wherein the processor is fiiither 
configured to notify the buyer that the purdiase offer has lapsed if the purchase offer 
expires without being accepted. 

30 

13. The computer device as claimed in claim 1 or 4, wherein the binding purchase 
offer is not valid until a predetermined date. 
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14. The computer device as claimed in claim 1 or 4, wherein the processor is further 
configured to determine whether the binding purchase oHer has been revoked prior to any 
acceptance. 

5 15. The computer device as claimed in claim 1 or 4, wherein the binding purchase 
ofTer contains the condition that the buyer has the right to withdraw its ofTer after the 
first-accepting seller accepts the offer provided that the buyer pays a specified penalty to 
the fitst-accepting seller. 

10 16. The computer device as claimed in claim I or 4, wherein the binding purchase 
offer is cryptographically signed by the prospective buyer. 

17. The computer device as claimed in claim I or 4, wherein the processor is iiirther 
configured to collect payment for the purchase from the buyer. 

13 

18. The computer device as claimed in claim 1 or 4, wherein the processor is further 
configured to transmit buyer credit card infoimation and autiiorization to the first- 
accepting seller. 

20 19. The computer device as claimed in claim 1 or 4, wherein the processor is fiirther 
configured to placed payment collected from the buyer in an escrow account. 

20. The computer device as claimed in claim 1 or 4, wherein the payment for the 
purdiase is collected from the buyer on an instalment basis. 

M 

2 1 . The computer device as claimed in claim 1 or 4, wherein the processor is fiirther 
configured to remit payment for the purchase to the first-accepting seller, 

22. The computer device as claimed in claim 1 or 4, wherein the processor is further 
K configured to transfo- payment finm the buyer to the first-accepting seller. 

23. The computer device as claimed in claim 22, wherein fbe payment for the 
purchase is remitted to the first-accepting seller immediately upon acceptance of the 
purchase offer. 
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24. The computer device as claimed in claim 1 or 4, wherein the processor is fiuther 
configured to authenticate at least one of the origin and integrity of transmissions 
exchstnged between the potential buyer and potential sellers. 

3 25. The computer device as claimed in claim 1 or 4, wherein the processor is further 
configured to make the purchase offer available to potential sellers without identifying the 
prospective buyer. 

26. The computer device as claimed in claims I or 4, wherein the binding purchase 
10 offer is for goods. 
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27. A system for processing airline ticket sales, said syst«n comprising: 

3 communications port for obtaining a binding purchase offer for travel from a 
customer and one or more rules from a plurality of sellers of airline tickets, said binding 
purchase offer containing at least one customer-defined condition and each of said rules 
containing one or more airline-defined restrictions, said airline-defined restrictions 
including a price which is not disclosed to said customer, and 

processing means for comparing said binding purchase offer to said rules to 
determine whether any of said sellers of airline tickets is willing to accept said binding 
purchase offer if said customer-defined conditions satisfy said airline-defined restrictions 
of at least one of said rules, and for providing an acceptance of said binding purchase 
offer to said customer if said at least one customer-defined condition satisfies said 
restriction. 



IS 28. A system for processing the sale ofgoods or services, said system comprising: 

a communications port for obtaining a binding purchase offer from a customer 
for the purchase of said goods or services and one or more rules fiom a plurality of 
sellers, said binding purchase offer containing at least one customer-defined condition 
and each of said rules containing one or more seller-defined restrictions, said seller- 
defined restrictions including a price which is not disclosed to said customer, and 

a processor for comparing said binding purchase offer to said rules to detemiine 
whether any of said sellers is willing to accept said binding purchase offer if said 
customer-defined conditions satisfy said seller-defined restrictions of at least one of said 
rules, and for providing an acceptance of said binding purchase offer to said customer if 
said at least one customer-defined condition satisfies said restrictions. 



(tlUaCCIUMAcU 



30 



-165- 



29. The system accoiding to claim 27 or 28, wherein said piocessor identifies a 
product satisfying said customer-defined conditions. 

30. The system according to claim 27 or 28, wherein said processor binds said 
customer if said customer-defined conditions satisfy said restrictions. 

31. The system according to claim 27 or 28, further comprising one or more remote 
servers for storing at least a portion of said rules. 

32. The system according to claim 27 or 28, fiiither comprising at least one revenue 
management system and wherein at least a portion of said rules are generated by said at 
least one revenue management system. 

33. The system according to claim 27 or 28, wherein said processor generates a 
coimteiofier if said binding purchase ofTer is not accepted and said binding purchase offer 
is within a predefined tolerance of at least one of said rules. 

34. The system according to claim 27 or 28, wherein said Festiictions include a 
minimum price and said processor prevents said customer &om identifying said minimum 
price. 

35. The system according to claim 34, wherdn said processor prevents said customer 
from identifying said minimum price by limiting the number of said binding purchase 
ofTers which may be obtained from a given customer in a predefined period. 

36. The system according to claim 34. whaein said processor prevents said customer 
from identifying said minimum price by assessing a penalty to said customer if a ticket is 
not booked when an airline accqjts said binding purchase offer. 

37. The system according to claim 34, wherein said processor prevents said customer 
fiom identi^ng said minimum price by evaluating a rating of said customer containing 
information regarding the likelihood that said customo* mil book a ticket corresponding 
to said binding purchase offer. 
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3S. The system accoiding to claim 34, wherein said processor prevents said customer 
&om identifying said minimum price by binding said customer to purchase said airline 
ticket if said customer-defined conditions satisfy said airline-defined restrictions. 

i 39. A method of processing airline ticket sales, s^d method comprising the steps of: 
obtaining a binding purchase offer for travel from a customer, said binding 
purchase offer containing at least one customer-defined condition including a price; 

identifying one or more rules finm a plurality of sellers of airline tickets, each of 
said rules containing one or more airline-defined restrictions including a price -which is 
10 not disclosed to said customer, 

comparing said binding purchase offer to said rales to determine whether any of 
said sellers of airline tickets is willing to accept said binding purchase offer if said 
customer-defined conditions satisfy said airline-defmed restrictions of at least one of said 
rules, and providing an accq}tance of said binding purchase offer to said customer if said 
IS at least one customer-defined condition satisfies said airline-defined restrictions. 



40. A system for processing cruise ticket sales, said system comprising: 

20 a communication port for obtaining a binding purchase offer for travel from a 

customer and for receiving one or more rales fix>m a plurality of sellers of cruise tickets, 
said binding purchase offer containing at least one customer-defined condition including a 
price and each of said rules containing one or more cruise operator-defined restrictions 
including a price which is not disclosed to said customer, and 

25 a processor for comparing said binding purchase offer to said rules to determine 

wheth«' said customer-defined condition satisfies each of said cruise operator-defined 
restrictions of at least one of said rules, and for providing an acceptance of said binding 
purchase offer to said customer if said customer-defined condition satisfies said 
restrictions. 

41. A systan for processing cruise twket sales, said system comprising: 

a communications port for obtaining a binding purchase offer for said crmse 
ticket from a customer and for providing said binding purchase offer to a plurality of 
potential sellers of cruise tidcets, said binding purchase offer containing at least one 
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cusiomer-defined condition and a payment identifier for specifying a general-purpose 
account from which fimds may be paid; and 

a processor for detenniiiing if one or more of said carriers accepts said binding 
purchase offer, for binding said customer to purchase said cruise ticket if an acceptance is 
s received for said binding purchase offer and for providing an acceptance of said binding 
purchase offer to said customer. 



42. The system according to claim 40 or 41, wherein said customer-defined 
ID condition includes a specified itinerary. 

43. The system according to claim 40 or 41, wherein said customer-defined 
condition includes a level of service. 

13 44. The system according to claim 40 or 41, wherein said customer-defined 
condition includes a maximum price. 

45. A system for processing the sale of a product, said system comprising: 

a conununications port for obtaining a binding purchase offer fiom a customer, 
» said binding purchase offer containing at least one customer-defined condition and a 
payment identifier for specifying a credit card account from which fimds may be paid; 
and 

a processor for (i) determining if one or more of said carriers accepts said 
binding purchase offer and identifies a product satisfying said customer-defined 
2} condition; (ii) binding said customer to purchase said cruise ticket if an acceptance is 
received for said purchase offer and (iii) transmitting notification to the customer that the 
binding puirihase offer was accepted by a fiist-accepting seller without revealing the 
identify to the seller. 




io 46. A method ofprocessing cruise ticket sales, said method comprising the steps of: 
obtaining binding a purchase offer for travel from a customer, said binding 
purchase offer containing at least one customer-defined coiulition; 

identi^ng one or more rules fiom a plurality of sellers of cruise tickets, each of 
said rules containing one or more cruise operator-defined restrictions including a price 
which is not disclosed to said customer, 
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btnding said customer to purchase said cruise ticket if said customer-defined 
condition satisfies each of said cruise operator-defined restrictions of at least one of said 
rules; and 

transmitting notification to the buyer that the binding purchase offer was 
5 accepted by a seller without revealing the identity of the seller. 
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47. A method of processing cruise licket sales, said method comprising the steps of: 
obtaining a binding purchase offer for said cruise ticket from a customer, said 

binding purchase offer containing at least one customer-defined condition and a payment 
identifier for specifying a general-purpose account bom which fimds may be paid; 

providing said binding purchase offer to a plurality of potential sellers of said 
cruise tickets; 

receiving from one or more of said sellers an acceptance of said binding 
purchase offer, 

binding said customer to purchase said cruise ticket if an acceptance is received 
for said binding purchase offer; and transmitting notification to the buyer that the binding 
purchase offer was accepted by a seller without revealing the identity of the seller. 

48. A system for processing long distance calls, said system comprising: 

a communications port for obtaining a binding purchase offer from a customer 
for one or more telephone calls and for providing said purchase offer to a plurality of 
potential cartieis, said binding purchase oSa cantaining at least one customer-defined 
condition including a price and a payment identifier for specifying a manner in which 
fiinds will be paid; and 

a processor for determining if one or mere of said carriers accepts said binding 
pviichase offer, for binding said customer to purchase said telephone calls if an acceptance 
is received for said binding purchase ofTer and transmitting notification to the customer 
that the binding purchase was accepted by a seller without revealing the identity of the 
seller. 




49. A system for processing long distance calls, said system comprising: 

a communication port for obtaining a binding purcbase offer fix>m a customer for 
one or more telephone calls and for receiving one or more mles from a plurality of 
carriers, said binding purchase offer containing at least one customer-defined condition 
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including a price and each of said rules containing one or more cairier-defined restrictions 
including a price which is not disclosed to said customer, and 

a processor for comparing ssud purchase ofTer to said rules to determine whether 
any of said carriers is willing to accept said binding purchase offer if said customer- 
5 defined condition satisfies each of said cairier-defined restrictions of at least one of said 
rules, and for providing an acceptance of said binding purchase offer to said customer if 
said at least one customer-defined condition satisfies said catrier-defined restrictions. 

30. The system according to claim 48, wherein said processor initiates the use of said 
10 payment identifier to collect payment. 

SI. The system according to claim 48, wherein said fiinds may be paid from a 
general purpose account 

.... 19 52. The system according to claim 4S, wherein said iiiads are charged to a periodic 

• • • 

telephone service bill issued by a telephone service provider. 

« — 
•••• 

y.V . S3. The system according to claim 4S or 49, wherein said binding purchase offer is 

received from a telephone set configured to transmit said purchase ofTers. 

20 

• 54. The system according to claim 48 or 49, wherein said binding purchase offer Is 

^••••^ for apackage of calls to one or more called parties. 

5' •** 

55. The system according to claim 48 or 49, wherein said binding purchase offer is 

mVmVmX ^ ^ tclephoue service contract for a predefined period of time. 
■ • 

56. The system according to claim 48 or 49, wherein said binding purchase offer is 
for a telephone service contract for a predefined amount of money. 

30 57. The system according to claim 48 or 49, wherein said customer-defined 
condition specifies a particular time of day for said one or more telephone calls. 

SS. The system according to claim 48 or 49, wherein said customer-defined 
condition specifies a minimum duration for said one or more telqihone calls. 
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59. The system according to claim 48 or 49, wherein said customer-defined 
condition specifies a maximum duration for said one or more telephone calls. 

60. The system according to claim 48 or 49, wherein said customer-defined 
5 condition includes a telephone number of a paity to be called. 

61. The system according to claim 48 or 49, wherein said communication port is 
connected to a telephone network. 

10 62. The system according to claim 48 or 49, wherein said communication port is 
connected to an electronic network. 

63. A method of processing long distance calls, said method comprising the steps of: 
obtaining a binding purchase ofier from a customer for one or more telephone 
I i calls, said binding purchase offer containing at least one customer-defined condition and a 

payment identifier for specifying a manner in which funds will be paid; 
providing said purchase offer to a plurality of potential carriers; 
receiving from oae or more of said carriers an acceptance of said binding 

purchase offer; 

20 binding said customer to purchase said telephone calls if an acceptance is 

received for said binding purchase offer, and 

transmitting notification to the customer that the binding purchase offer was 
accepted by a seller without revealing the identity of the seller. 




64. A method of processing long distance calls, said method comprising the steps of: 
obtaining a binding purchase offer from a customer for one or more telephone 
calls, said binding purchase offer containing at least one customer-defined condition 
including a price; 

identifying one or more rules from a plurality of long distance carriers each of 
said rules containing one or more carrier-defined restrictions including a price which is 
not disclosed to said customer; 

bmding said customer to purchase said telephone calls if said customar-defined 
condition satisfies each of said canier-defined resliictions of at least one of said niles; and 

providing an acceptance of said binding purchase offer to said customer if said 
customar-defined condition satisfies said cairier-<fefined restrictions. 
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65. A computer device for consummating a binding contract between a remote 
prospective event ticket buyer and a remote potential event ticket seller, said computer 
device comprising: 

i a memory device; and 

a processor disposed In connection with said memory device, said processor 
configured to: 

receive from said buyer a purchase offer for an event ticket, said offer 
containing at least one condition, an accoimt number from a general purpose financial 
10 account, and authorization to charge said general purpose fmancial account for a purchase 
meeting said at least one condition; 

transmit said purchase offer to a plurality of remote potential event ticket sellers; 
receive fiom at least one of said remote potential event ticket sellers an 
unconditional acceptance of said offer; 
13 determine a replacement ticket identifier associated with said event ticket; and 

transmit said replacement ticket identifier to said buyer. 

66. The device as claimed in claim 6S, wherein said processor is further configured 
to receive a second general purpose financial account number from said seller and 

20 authorization to charge said second general puipose account number for a penalty applied 
to an account of said seller. 

67. The device as claimed in claim 6S, wherein said processor is fiuther configured 
to process paymrat to said seller upon receiving a signal representing surrender of said 

u event ticket by said seller. 

68. The device as claimed in claim 65, wherein said processor is further configured 
to process payment to said seller upon receiving a ticket number associated with said 
event ticket. 

30 

69. The device as claimed in claim 65, wherein said processor is fiittfaer configured 
to process a cancellation of said event ticket. 




70. The device as claimed in claim 65, wherein said processor is fiuther configured 
to receive and store a name of said buyer associated with said event ticket. 
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71. The device as claimed in claim 6S, wherein said processor is further configured 
to transmii to a venue controller a ticket identifier associated with said event ticket. 

72. The device as claimed in claim 71, wherein said processor is configured to 
determine said replacement ticket identifier by being fiirther configured to receive said 
replacement ticket identifier fixim said venue controller. 

73. The device as claimed in claim 65, wherein said tqilaceraent ticket identifier 
includes an original ticket identifier. 

74. A computer device for managing replacement identifiers for event tickets, said 
computer device comprising: 

a memory device; and 

a processor disposed in connection with said memory device, said processor 
configured to receive from a central controller a request for a replacement ticket number, 
said request including an original ticket number; said processor further configured to 
determine said replacement ticket niunber, transmit said replacement ticket number to 
said central eontrolle; and store said origina] ticket number and said associated 
leplacement ticket number at said memory device. 

75. The device as claimed in claim 74, wherein said processor is fiirther configured 
to receive identity data representing an identity of a buyer, and store said identity data at 
said memory device for associatiDn with said oiiginal ticket number and said replacement 
ticket number. 

76. K method of processing sales of items, said method comprising the steps of: 
receiving an offer signal induding at least one condition signal, the offer signal 

thereby defuiing an offer having at least one condition fiom a customer; 

receiving a payment Identifier signal for specifying an account fiom which fluids 
may be paid; 

recdving an infoimational signal relevant to the oSa fiom a third party; 
transmitting the offer signal and the informational signal to at least one seller: 
receiving fiom at least one of the at least one seller an acceptance signal 
re^onsive to the transmitted offer signal and the transmitted infoimaiiiHial signal; and 
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selectingone acceptance signal. 

77. An appaiatus for processing sales of items, said apparatus comprising: 
a storage device; and 

a processor connected to the storage device, 

the storage device storing a program for controlling the processor; and 
the processor iterative with the program to: 

receive an offer signal including at least one condition signal, the offer 
signal thereby defining an offer having at least one condition &om a customer, 

receive a payment identifier signal for specifying an account from 
which funds may be paid, 

receive an informational signal relevant to the offer from a third party, 
transmit the offer signal and the informational signal to at least one 

seller, 

receive from at least one of the at least one seller an acceptance signal 
responsive to the tiansmitted offer signal and the transmitted infoimational signal, and 
selecting one acceptance signal. 

78. The apparatus as claimed in claini 77, wherein the processor is further operative 
with the program to: 

identify the seller from which the selected acceptance signal was recdved. 

79. The apparatus as claimed in claim 77, wherein the processor is further operative 
with the program to: 

initiate the use of the payment identifier signal to collect the fimds. 

80. The apparatus as claimed in claim 79, wherein the processor is fiirtbei operative 
with the program to transmit flie payment identifier signal to the at least one seller. 

8 1 . The apparatus as claimed in claim 77, wherein the processor is further operative 
with the program to: 

validate the received offer signal, and thereby determine whether the received 
offer signal meets ptedaennined validation criteria. 
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82. The apparatus as claimed in claim 81, wherein the processor is further operative 
with the program to transmit the offer signal and Uie informational signal only if the step 
of validating determines that the received oCfer signal meets the predetennined validation 
criteria. 

83. The apparatus as claimed in claim 77, wherein the processor is further operative 
with the program to select the first received acceptance signal, 

84. The apparatus as claimed in claim 77, wherein the processor is further operative 
with the program to select a random one of the plurality of acceptance signals if a 
plurality of acceptance signals are received. 

85. The ^aratus as claimed in claim 77, wherein the processor is further operative 
with the program to 

if a plurality of acceptance signals are received, 

sort the plurality of acceptance signals according to a predeteimined sort 

criteria, and 

select the first of the sorted plurality of acceptance signals. 

86. The apparatus as claimed in claim 77, wherein the processor is farther operative 
with the program to 

if a plurality of acceptance signals are received, 

transmit a plurality of seller signals, each indicative of a seller which 
conesponds to one of the plurality of acceptance signals, 

receive a selection signal indicative of a selected seller signal, and 
thereby indicate a corresponding acceptance signal, and 

select the acceptance signal corresponding to the selected seller signal. 

87. An qipaiatus for processing sales of items, said ^aratus comprising: 
a storage device; and 

a processor connected to the storage device, a borrower tominal and at least one 
lender tetmioal, 

the storage device storing a program for controlling the processor, and 
the processor operative with the program to 
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leceive an offer signal including at least one 
condition signal, the offer signa] defining a binding purchase offtr having at least one 
condition including a price from a customer; 

receive a payment identifier signal for 
s specifying an account from which fiinds may be paid; 

receive an informational signal relevant to the 

offer from a third party; 

store at least one rule signal from each of a 
plurality of sellers, each rule signal including at least one seller-defined restriction; 
10 compare the offer signal and the 

informational signal with at least one rule signal; 

determine whether the at least one condition 
and the informational signal satisfy each seller-defined restrictian of any rule; and 

provide an acceptance of said binding 
15 purchase offer if said at least one condition satisfies said seller-defined restriction of any 
rule. 




88. The apparatus as claimed in claim 87, wherein the processor is further optative 
with the program to: 

if a plurality of rules are satisfied, select one of the plurality of satisfied rules, 

89. The apparatus as claimed in claim 88, wherein the processor is iiirther operative 
with the program to: 

select a random one of the plurality of satisfied rules. 

90. The apparatus as claimed in claim 88, wherein the processor is fiirthet operative 
with the program lo: 

transmit a plurality of lender signals, each indicative of a loider which 
corresponds to one of the plurality of satisfied rules; 

receive a selection signal indicative of a selected lender signal, and thereby 
indicate a corresponding rule; and 

select the satisfied rule corresponding to the selected lender signal. 

91. A method for using a computer to facilitate a transaction between a buyer and at 
least one of a plurality of sellers, said method comprising the steps of: 
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inputting into the computer a conditional purchase ofTer which includes an oiTer 

price; 

inputting into the computer a payment identifier specifying a credit card account, 
the paynnent identifier being associated with the conditional purchase offer; 

outpuuing the conditional purchase offer to the plurality of sellers after receiving 
the payment identifier; 

inputting into the computer an acceptance fix)m a seller, the acceptance being 
responsive to the conditional purchase offer; and 

providing a payment to the seller by using the payment identifier. 

92. The method as claimed in claim 91, in which the step of inputting into the 
computer an acceptance comprises: 

inputting into the computer an acceptance liom each tnember of a set of sellers, 
the set of sellers comprising at least one seller, each acceptance being responsive to the 
conditional purchase offer, 

and fiirther comprising: 

selecting one received acceptance, thereby detemiining a selected seller of the set 
of sellers; 

and in which the step of providing a payment comprises: 

providing a payment to the selected seller by using the payment identifier. 

93 . The method as claimed in claim 9 1 , further comprising: 

determining if a predetermined amount is available in the credit card account. 

94. The method as claimed in claim 91, further comprising: 

outputting to the buyer a request for an authorization to use the payment 
identifia to provide payment if an acceptance is received; and 

inputting into the computer the authorization from the buyer in response to the 

request. 

95. The method as claimed in claim 91, in which the step of inputting into the 
computer an acceptance comprises: 

inputting into the computer an acceptance Smm each of a set of sellers. 

96. The method as claimed in claim 9 1 , fiiither comprising: 
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detennining an active period during which the conditional purchase ofTer is 
active; and in which the step of inputting into the computer an acceptance is performed 
during the active period. 

s 97. The method as claimed in claim 9 1 , further comprising: 

inputting into the computer a revocation of the conditional purchase offer after 
the step of receiving an acceptance; and in which the step of providing a payment 
comprises; 

providing a payment of a predetermined amount to the seller. 

10 

98. The method as claimed in claim 92, in which the step of selecting one received 
acceptance comprises'. 

determining a first received acceptance, thereby determining a first seller of the 
set of sellers; 

IS and in which the step of providing a payment compiises: 

providing a payment to the first seller by using the payment identifier. 

99. An apparatus for facilitating a transaction between a buyer and at least one of a 
plurality of sellers, said apparatus comprising: 

:o a storage device; and 

a processor connected to the storage device, 

the storage device storing 

a program for controlling the processor, and 

the processor operative with the program to receive a conditional ptiichase offer 
jj which includes an offer price; 

receive a payment identifier specifying a credit card account, the payment 
identifier being associated with the conditional ptmdiase of&r, 

make die conditional purchase ofTer available to the plurality of sellers afier 
receiving the payment identifier, 
M receive an accq>tance from a seller, the axxeptance being responsive to the 

conditional purchase o£^ and 

provide payment to the selected seller by using the payment idmtifier. 

100. A method for using a computer to fiicilitate a transaction between a buyer and at 
east one of a plurality of sellers, said meAod comprising the steps of: 
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inputting into the computer a conditional purchase offer which includes an offer 

price; 

inputting into the computer a payment identifier specifying a financial account, 
the payment identifier being associated with the conditional purchase offer; 
s outputting to the buyer a request for authorization to use the payment identifier 

to provide a payment if an acceptance is received; 

inputting into the connputer authorization from the buyer in response to the 

lequest; 

outputting the conditional purchase offer to the plurality of sellers after receiving 
10 payment identifier; 

inputting into the computer an acceptance from a seller, the acceptance being 
responsive to the conditional purchase offer; and 

providiiig the payment to the seller by using the payment identifier. 

IS 1 01 . An apparatus for facilitating a transaction between a buyer and at least one of a 
plurality of sellers, said apparatus comprising: 
a storage device; and 

a processor connected to the storage device, 

the storage device storing 
20 a program for controlling the processor, and 

the processor operative with the program to receive a conditional purchase offer 
which includes an offer pric^ 

receive a payment identifier specifying a financial account, the payment 
identifier being associated with the conditiona] purchase offer; 
2} output to the buyer a request for an authorization to use the payment identifier to 

provide a payment if an acceptance is received; 

received the authorization from the buyer in response to the request; 

transmit the conditional purchase offer to the plurality of sellers after receiving 
the payment identifier, 

M receive an acceptance from a seller, the accqitance being responsive to the 

transmitted conditional purchase offer; and 

provide the payment to the seller by using the payment identifier. 

102. The apparatus as claimed in claim 99, in which the processor is further operative 
with the program to: 
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receive an acceptance from each member of a set of selleis, the set of sellers 
comprising at least one seller, each acceptance being responsive to the conditional 
purchase offer, 

select one received acceptance, thereby deterniining a selected seller of the set of 
s sellers; and 

provide a payment to the selected seller by using the payment identifier. 

103. The apparatus as claimed in claim 102, in which the processor is further 
operative with the program to: 
ID determine a first acceptance received, thereby determining a first seller of the set 

of sellers; and 

provide a payment to the first seller by using the payment identifier. 
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104. The apparatus as claimed in claim 99, in which the processor is further operative 
15 with the program to: 

determine if a predetermined amount is available in the credit catd account. 

105. The ^paratus as claimed in claim 99, in wtuch the processor is further operative 
with the program to: 

10 transfer payment from the buyer to the seller. 

106. The apparatus as claimed in claim 99, in whidi the processor is further operative 
with the program to: 

transmit the payment identifier to the seller. 

107. The apparatus as claimed in claim 99, in which the processor is fiirther operative 
with tiie program to: 

output to the buyer a request for an authorization to use the payment identiGer to 
provide payment if an acceptance is received; and 
M receive the auiharizaii<»i fiom the buyer in response to the request. 



108. The apparatus as claimed in claim 99, in which the processor is further operative 
with the program to: 




receive an acceptance 6om each of a set of sellers. 
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109. The apparatus as claimed in claim 99, in which the conditional purchase ofler 
includes an expitation date and is non-revocable prior to the expiration date. 

1 10. The apparatus as claimed in claim 99, in which the processor is further operative 
I with the program to: 

determine an active period during which the conditional purchase ofier is active; 

and 

receive an acceptance during the acting period. 

10 111. The apparatus as claimed in claim 99, in which the processor is fiuther operative 
with the program to: 

receive a revocation of the conditional purchase offer after receiving an 
acceptance; and 

provide a payment of a predetermined amoimt to the seller. 

15 

112. The method as claimed in claim 100, in which the step of inputting into the 
computer an acceptance comprises: 

inputting into the computer an acceptance from each member of a set of sellers, 
the set of sellers comprising at least one seller, each acceptance being responave to the 
30 conditional purchase offer; 

and ftuther comprising: 

selecting one received acceptance, thereby determining a selected seller of the set 
of sellers; 

and in which the step of providing a payment coiiQ>rises: 
25 providing a payment to the selected seller by using the payment identifier. 

113. The method as claimed in claim 1 1 2, in which the step of selecting an acceptance 
received comprises: 

determining a first acceptance received, therdiy deteimining a first seller of the 
M at least one seller; 

and in which the step of providing a payment comprises: 

providing a payment to ttie first seller by using the payment identifier. 

114. The method as claimed in claim 100, in which the financial account is a credit 
d account. 




-181- 



115. The method as claimed in claim 1 14, iiirther comprising: 

detennining if a piedetomincd amount is available in the credit card account. 

1 1 6. The method as claimed in claim 100, fUrthcr comprising: 
transferring payment from the buyer to the seller. 

1 1 7. The method as claimed In claim 100, in which the step of providing a payment 
comprises: 

transmitting the payment identifier to the seller. 

118. The method as claimed in claim 100, in which the step of inputting into the 
computer an acceptance comprises: 

inputting into tiie computer an acceptance &om each of a set of sellers. 

119. The method as claimed in claim 100, in which the conditional purchase offa: 
includes an expiration date and in non-revocable prior to the expiration date. 

120. The method as claimed in claim 100, fiiither comprising: 

determining an active period during which the conditional purchase offer is 

active; 

and in which step of inputting into the computer an acceptance is performed 
during the active period. 

121. The method as claimed in claim 100, fiirther comprising: 

inputting into the computer a revocation of the conditional purchase offer after 
the step of receiving an acceptance and in which the stq> of providing a payment 
comprises: 

providing a payment of a predetermined amount to the seller. 

122. The apparatus as claimed In claim 101, in which the processor is further 
operative with the program to: 

receive an acceptance from each member of a set of sellers, the set of sellers 
comprising at least one seller, each acceptance being responsive to the conditional 
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puichase oiTer, select one received acceptance, thereby deteimining a selected seller of 
the set of sellers; and 

provide a payment to the selected seller by using the payment identifier. 

s 123. The apparatus as claimed in claim 121, in which the processor is fiirther 
operative with the program to: 

determine a first accqjtance received, thereby dttermining a first seller of the set 
of sellers; and 

provide a payment to the first seller by using the paymenl identifier. 

10 

124. The apparatus as claimed in claim 101, in which the financial account is a credit 
card account. 

125. The apparatus as claimed in claim 123, in which the processor is fiuther 
I s optative with the program to: 

determine if a predetermined amount is available m the financial account. 

126. The apparatus as claimed in claim 101, in which the processor is fiirther 
operative with the program to: 

20 transfer payment firom the buyer to the seller. 

127. The apparatus as claimed in claim 101. in which the processor is fiirther 
operative with the program to: 

transmit the payment identifier to the seller. 

25 

128. The apparatus as claimed in clahn 101, in which the processor is fiirther 
operative with Oie program to: 

receive an acceptance fi^om each of a set of sellers. 

30 129. The apparatus as claimed in claim 101, in which the conditional purchase offer 
includes an expiration date and is non-revocable prior to the expiration date. 

130. The apparatus as claimed in claim 101, in which the processor is fiirther 
?^M^5Dperative with the program to; 
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detennine an active period during which the conditional purchase offer is active; 

and 

receive an acceptance during the active period. 

5 131. The apparatus as claimed in claim 101, in which the processor is fiirther 
operative with the program to: 

receive a revocation of the conditional purchase offer after receiving an 
acceptance; and provide a payment of a predetemiined amount to the seller. 

10 132. A system, comprising: 

a server providing a web page accessible by customers; 
a storage device storing a program; 

a processor in communication with said storage device, said processor operative 
with said program to: 

IS receive a selection of a subject of goods or services from a customer utilizing the 

web page; 

receive a conditional purchase offer from a customer utilizing said web page for 
purchasing goods or services, said conditional purchase offer specifying at least one 
condition of the conditional purchase offer and an offer price; 
30 receive a payment identifier specifying a financial account for use in providing 

payment for said goods or services if said condidonal purchase offer is accepted; 

compare said conditional purchase offer m&i seller inventory and pricing 
information to determine if said conditional purchase offer is acceptable; 

if said conditional purchase offer is acceptable, provide an acceptance to said 
25 customer in response to the conditiotkal purchase offer, 

charge said financial account &r payment of sud goods or services; and provide 
payment to said goods or services. 

133. The system as claimed in claim 132, wherein said conditional purchase offer 
30 includes an expiration date. 

134. The system as claimed in claim 132, whonn said seller inventory and pricing 
information includes seller-defined rules. 




IUUICCPOUkW 



-184- 



13S. The system as claimed in claim 132, wlierein the customer accesses said web 
page using a web browser. 



136. The system as claimed in claim 132, wherein said financial account is a debit 
s account. 

1 37. The system as clamed in claim 132, wherein said financial account is a credit 
account. 



10 138. The system as claimed in claim 132, wherein said processor is fiirther operative 
with said progress to pre-authorize said offer price of said conditional purchase offer with 
a financial clearinghouse. 

139. The system as claimed in claim 138, wherein said payment for said goods and 
I s services is guaranteed. 

14Q, The system as claimed in claim 132, wherein said payment to said seller for 
goods or services is provided with fiuids charged to said financial account 

20 141. The syston as claimed in claim 132, wherein said processor is fiirther operative 
with said program to: 

calculate a discounted value of the offer price; 
charge said financial account for the offer price; and 

provide payment to said seller for said goods or services of an amount equal to a 
25 percentage of the offer price. 

142. The system as claimed in claim 141, wherein the difference between the offer 
price and the payment to the seller is an imdisclosed profit margia. 

30 143. The system as clmmed in claim 132, wherein said processor is ftnther operative 
with said program to authenticate said conditional purchase offer prior to consideration 
thereof. 




144. The system as claimed in claim 143, wherein authentication of said conditional 
purchase oSet includes acceptance of a customer credit card number. 
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145, The system as claimed ia claim 132, wherein acceptance to said customer is 
provided without indication of amounts paid to a seller for said goods or services. 

1 46. A method for using a computer to process the sale of goods or services, said 
method comprising the steps of: 

receiving a selection of a subject of goods or services from a customer utiUzing a 
web page; 

receiving a conditional purchase otkr from a customer utilizing said web page 
for purchasing goods or services, said conditional purchase offer specifying at least one 
condition of the conditional purchase offer and an offer price; 

receiving a payment identifier specifying a financial account for use in providing 
payment for said goods or services if said conditional purchase offer is accepted; 

comparing said conditional putchase offer with seller inventory and pricing 
information to determine if said conditional purchase offer is acceptable; 

if said conditional purchase offer is acceptable, providing an acceptance to said 
cu^omer in response to the conditional purchase offer; 

charging said financial account for payment of said goods or services; and 
providing payment to said seller for said goods or services. 



30 




147. A system, comprising: 

a server providing a web page accessible by customer; 
a storage device storing a program; 

a processor in conununication with said storage device, said processor operative 
with said program to: 

receive a selection of a subject of goods or sovices from a customer utilizing the 
web page; 

receive a conditional purchase ofler from a customer utilizing said web page for 
purchasing goods or services, said conditional purchase offer specifying at least one 
condition of the conditional putdiase offer and an offer price; 

receive a payment identifier specifying a financial account fiir use in providing 
payment for said goods or services if said conditional purchase offer is accepted; 

compare said conditional purchase offa with seller inventory and pricing 
infiirmation to determine if said conditional purchase offer is acceptable; 
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if said conditional purchase olTer is accqjtable, provide an acceptance to said 
customer in response to the conditional puichase oiTei; 

charge said financial account for payment of said goods or services; and 
provide payment for said goods or services to said seller, wherein said financial 
account is charged by an entity other than the seller. 

148. The system as claimed in claim 147, wherein said conditional purchase offer 
includes an expiration date.' 

149. The system as claimed in claim 147, wherein said seller inventory and pricing 
informatioa includes seller-defined niles. 

150. The system as claimed in claim 147, wherein the customer accesses said web 
page using a web browser. 

151. The system as claimed in claim 147, wherein said fmancial account is a debit 
account. 

152. The system as claimed in claim 147, wherein said financial account is a credit 
account. 

153. A system, comprising: 

a server providing a web page accessible by customer, 

a storage device storing a program; 

a prcx;essor in communication with said storage device, said processor operative 
with said program to: 

receive a selection of a subject of goods or services from a customer utiliziag the 
web page; 

receive a conditional purchase offer from a customer utilizing said web page for 
purchasing goods or services, said conditional purchase offer specifying at least one 
condition of the conditional puichase offer and an offer price; 

receive a paymwit identifier specifying a financial account for use in providing 
payment for said goods or services if said conditional purchase offer is accepted; 
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compare said conditional purchase offer with seller inventory and pricing 
information to determine if said conditional purchase offer is acceptable without 
identification of the seller to the customer; 

if said conditional purchase offer is acceptable, provide an acceptance to said 
} customer in response to the conditional purchase offer; 

charge said financial account for payment of said goods or services; and 

provide payment to said seller for said goods or services. 

154. The system as claimed in claim 153, wherein said conditional purchase offer 
10 includes an expiration date. 

155. The system as claimed in claim 153, whetein said seller inventory and pricing 
infomialion includes seller-defined rules. 



15 1S6. The system as claimed in claim 153, wherein the customer accesses said web 
page using a web browser. 

157. The system as claimed in claim 153, wheiein said financial account is a debit 
account. 

20 

158. The system as claimed in claim 153, wherein said financial account is a credit 
account. 

159. A system, comprising: 

2! a server providing a web page accessible by customers; 

a storage device storing a program; 

a processor in communication with said storage device, said processor operative 
with said program to: 

receive a selection of a subject of goods or services from a customer utilizing the 
10 web page; 

receive a conditional purchase oCfer including an offer price created by the 
costomer by filling out an electronic fonn fiom said web page for purchasing goods or 
services; 

receive a payment identifier specifying a financial account for use in providing 
payment for said goods or services if said conditional purchase offer is accq>ted; 
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compare said conditional purchase offer with seller inventory and pricing 
infonnation to determine if said conditional purchase offer is acceptable; 

if sud conditional purchase offer is acceptable, provide an acceptance to the 
customer in response to the conditional purchase offer; 
5 charge said financial account for payment of said goods or services; and provide 

payment to said seller for said goods and services. 

160. A method for using a computer to process the sale of goods or services, said 
method comprising the steps of 
10 receiving a selection of a subject of good or services from a customer utilizing 

the web page; 

receiving a conditional purchase offer including an offer price created by the 
customer by filling out an electronic form frwn said web page for purchasing goods or 
services; 

15 receiving a payment identifier specifying a financial account for use in providing 

• payment for said goods or services if said conditional purchase offer is accepted; 

comparing said conditional purchase offer with seller inventory and pricing 
information to determine if said conditional purchase offer is acceptable; 
: if said conditional purchase offer is acceptable, providing an acceptance to the 

20 customer response to the conditional purchase offer, 

, charging said financial account for payment of said goods or services; and 

providing payment to said seller for said goods or services. 

161. The method as claimed in clam 160, wherein said conditional purchase offer 
2s includes an expiration date. 

162. The method as claimed in claim 160, wherein said seller inventory and pricing 
infinrmation includes seller-defined rules. 

30 163. The method as claimed in claim 160, wherein the customer accesses said web 
page using a web page browser. 

164. The method as claimed in claim 160, wherein said financial account is a d^it 
account. 
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165. The method as claimed in claim 160, wherein said financial account is a credit 
account 

1 66. A system, comprising: 

a server providing a web page accessible by customeis using a web browser; a 
storage device storing a program; 

a processor in communication with said storage devices, said processor operative 
with said program to: 

receive a selection of a subject of goods or services fiom a customer utilizing the 
web page; 

receive a conditional purchase offer from a customer utilizing said web page for 
purchasing goods or services, said conditional purchase offer specifying at least one 
condition of the conditional purchase oSer, and an offer price, said conditional purchase 
offer being binding upon acceptance; 

receive a credit card number specifying a credit card account for use in providing 
guarantee payment for said goods or services if said conditional purchase offer is 
accepted; 

compare said conditional purchase offer with seller inventory and pricing 
information to determine if said conditional purchase ofira is acceptable without 
identification of the seller to the customer, 

if said conditional purchase offer is acceptable, provide an acceptance to the 
customer in response to the conditional purchase offer without indication of amounts paid 
to a seller for goods or services; 

charge said credit card account for payment of said goods or services; and 
provide payment to said seller for said goods or services of an amoimt less than and 
independent of said offer price. 

167. The system as claimed in claim 166, wherein said conditional purchase offer 
includes an expiration date. 

16S. The system as claimed in claim 166, wherein said seller inventoiy and pricing 
information includes seller-defined rules. 

169. ' The system as claimed in claim 166, wherein die customer accesses said web 
page using a web browser.. 
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170. The system as claimed in claim 166, wherein said financial account is a debit 
account. 

171. The system as claimed in claim 166, wherein said financial account is a credit 
account 

172. A computer device for consummating a binding contract between a remote 
prospective buyer and a remote potential seller, said computer device being substantially 
as described herein with reference to the accompanying drawings- 

173. A system substantially as described herein with reference to the accompanying 
drawings. 

174. A method of processing sales, said method being substantially as described 
herein with reference to the accompanying drawings. 

175. A computer device for managing replacement identifieis for event tickets, said 
computer device being substantially as described herein with reference to the 
accompanying drawings. 

176. An apparatus for processing sales of items, said apparatus being substantially as 
described herein with reference to the accompanying dnwing^. 

177. A method for using a computer to focilitate a transaction between a buyer and at 
least one of a pluraUty of sellers, said mediod being substantially as described herein with 
reference to the accompanying drawings. 

178. An apparatus for fiicilitating a transaction between a buyer and at least one of a 
plurality of sellers, said ^aratus being substantially as desmbed heieia with reference 
to the accompanying drawings. 
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